Week of Feb 1, 2016
In Swift 3, the look of the language is getting a redesign, which is governed by three interlinked proposals:
Based on the discussions, Dave Abrahams started afresh on reasoning about using function argument labels (
add(thingie:)) vs. merging the label with the function base name (
addThingie()) vs. dropping the label altogether (
add()), and revised it again.
Douglas Gregor made an importer with the revised scheme, and the results look like this.
Drew Crawford, Nate Cook and others strongly disapproved of dropping the
NSprefix for Foundation classes.
The Swift standard library defines Array, Set, and Dictionary as collection types with value semantics that operate quite differently from their peers in Foundation. This change will introduce OrderedSet, CountedSet, HashTable, MapTable, and others, all of which use reference semantics and therefore don’t provide the same set of guarantees about ownership and immutability.
As an example, the seemingly similar Set and CountedSet types produce different results from nearly identical code.
I think the juxtaposition of Array, String, Dictionary, and Set (mutable, with value semantics) and MutableArray, MutableString, MutableDictionary, and MutableSet (mutable, with reference semantics) is one of the most obvious problems with this part of the change.
Erica Sadun wrote about this proposal in general in her blog:
I’m not convinced that developers will welcome widespread API adjustments that may incur costs in code review, error detection, maintenance as well as the production of new code.
Dave Abrahams explained the reasons for proposing that “Generator”s be changed to “Iterators”:
- Iterator is the more well known concept
- The method name “generate()” was obviously wrong … Once you start thinking about other names for that, it leads naturally to considering other names for the things it returns.
Previously: Week of Jan 25.
This proposal was accepted, but this means that
#linemeans different things based on its position in a line.
#lineis in the middle of a line, it would be a debug identifier for the current line, like in:
print("At line \(#line) of file \(#file)")
#lineis at the start of a line, it’s a line control statement that tells the compiler to use that line number and filename for error messages (useful for in Swift code that is automatically-generated based on some other directive file).
#line 10 "foo.grammar"
Chris Lattner says:
The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose.
The alternatives being explored for the line control statement include renaming it to
#sourceline, or using a different syntax altogether, like
#reset line=50, file="foo.swift".
Up for review
Implicit tuple-splatting for function calls is a little-known and hardly-ever-used feature in Swift, and Chris Lattner proposes that it be removed.
Patrick Gili made a draft proposal to have regex literals in Swift, by introducing a Perl-like syntax for creating
But it turned out that Chris Lattner’s plans for regexes in Swift are different and much more ambitious. He said:
Instead of introducing regex literals, I’d suggest that you investigate introducing regex’s to the pattern grammar, which is what Swift uses for matching already. Regex’s should be usable in the cases of a switch, for example. Similarly, they should be able to bind variables directly to subpatterns.
Further, I highly recommend checking out Perl 6’s regular expressions. They are a community that has had an obsessive passion for regular expressions, and in Perl 6 they were given the chance to reinvent the wheel based on what they learned. What they came up with is very powerful, and pretty good all around.
And then, in another mail:
I think it would make a lot of sense for primitive types to support “default” regex rules (e.g. integers would default to /[0-9]+/ ) and then have modifier characters that support other standard modes for them (e.g. x for hexadecimal). This would obviously want to be extensible to arbitrary types, so that (e.g.) NSDate could support the format families that make sense.
There’s now an app to follow the Swift-related mailing lists: Hirundo
I find it very useful, and if you’d like to follow the discussions in more detail, you should definitely give this app a try.
- Jesse Squires’ Swift Weekly Brief Issue #8 talks about open-source Swift happenings last week