Here’s a short list of things that aren’t (or probably aren’t) going to be in Swift 3, that I was hoping to see.
Like my posts? Consider buying a book or two or three. Thanks!
Fixed Ranges, Striding, and Range Operators. This splintered down into a series of I believe four separate proposals of which only the first one (improving floating point math) has gotten into review. A lot more work to be done here. Plus extending striding to collections.
Disambiguating SPM Naming Conflicts. My idea would be to come up with a way to allow multiple packages to share the same simple names (like “JSON Parser”) and differentiate them based on their source repo. Swift names should be simple and concise. Namespacing modules (“MySwiftStringUtilityCollection”) is very unSwift so overlap is not just likely, it’s already happening.
The language would adjust to add import as as well, so same-named modules (or modules with difficult names, or submodules) could be pulled in with simpler access from code.
Most of this depends on the overworked and overwhelmed build team, plus it would then require a Swift Evolution proposal for the “import as” component. There are already bug reports of package conflicts in the wild and this would introduce a simple way to add resolution.
Introducing Build Configuration tests for Simulator/Device targets. I gave up on even trying to do #if debug (if one is going to do the configuration tests, there doesn’t seem to be a large enough middle group that wants a preconfigured simple test) but I think #if target(device) (vs simulator/emulator) is doable and useful. Backburnered, along with any platform tests (Windows, Linux, Unix, Apple) until there’s time.
Method Cascades. Dart-like for the win. Postponed until after 3.x at a minimum. It’s language additive, which makes it less critical for 3.
Interpolated String Formatting. Brent Royal Gordon started this off and then it went into limbo. I think it’s important to be able to not just add \(aFloat) into strings but be able to do some kind of inline safe formatting about the number of decimal places, leading zeros, etc.
Core Error. Not hugely popular but not entirely dead, I thought it would be nice to have a built-in basic “default error” to throw that included source site (where the error was thrown) and an optional customizable string and/or dictionary. This wouldn’t replace any other errors but it would provide a convenient error for anyone building scripts and playgrounds (or, let’s be honest, simple apps) where you didn’t want to build something more carefully and extensive with individual error condition cases.
Macros. Didn’t happen. Won’t happen for a while.
Decimal Numbers. Ditto.
Duplicating and modifying immutable structs. Brought up “with” on list, showed an implementation, it got discussed, went nowhere.
Final by default for Swift-sourced classes (would not apply to anything from ObjC), where you enable subclassing rather than disable it. Seemed to split down between Swifties (for it), ObjCHeads (against it).
A Result Type for use in completion blocks, rather than the data, status, error signature we currently have. Big war over Result (specific use case, measurable benefit) and Either (just a thing that could be built and used for this). I prefer Result.
Intrinsic Member Collection for Enumerations. There’s a pull request but that’s about it.
Expanding Cocoa Touch Defaults. The idea was to take a cue from the better-imports from ObjC (SE-0005) and extend the pruning and defaults to other common classes. This isn’t a Swift Evolution process but I have no contact point with whom to take it up with for Foundation and UIKit. (initial unreviewed list), and I’m not yet satisfied with which defaults I actually want to push on.
There’s actually two more items on my list that just might squeak through:
Adding the Unfold Sequence. Lily’s SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib in review to 5/23sequence -> UnfoldSequence was part of SE-0045 and the only part of the proposal not to be accepted. After a spate of bikeshedding, I think the name sequence() was not hated, but it’s unclear whether this needs a new proposal (it’s getting kind of late to the party) or can be shoehorned in.
Evan Maloney’s end to the Strong Weak Dance. I was writing this up, and I checked the pull request and behold, it is now in the proposal queue as SE-0079. Still not sure this will go through but it would make coding a lot better.
Okay, that’s my (partial) list. What’s yours?
7 Comments
Final by default was one I would have liked to see to. Fascinating the way the responses to that one split too.
Package name conflict resolution will surely need to be addressed at some point though…
Great list Erica. I hope we’re not too shy about making breaking changes where necessary in Swift 4 (final by default!).
Conditional protocol conformance and generalized existentials are the biggest missing features in the language IMO. These features will significantly increase the expressivity of the design options we have available. I’m really sad that they didn’t make it.
I hope we are absolutely shy about making breaking changes in Swift 4. I think too many breaking changes in Swift 4 would be the final nail in the coffin for Swift as a general purpose language (rather than just for Apple platforms) as everybody realises that Apple will be breaking their code every year from now on.
Final by default is also highly problematic for me in that it represents the philosophy “every thing is illegal except that which is explicitly permitted” as opposed to “everything is permitted except that which is explicitly banned”. Final by default will discourage code sharing by making behaviour of classes hard to modify. If Alice likes to design her classes carefully so that other programmers can use them and subclass them safely and Bob slaps his classes together just so they work for his use case but recognises that and wants to stop others from subclassing them, who do you think should be punished by having to put boiler-plate declaration modifiers everywhere?
I completely agree with Jeremy that any significant breaking changes in Swift 4 would be highly problematic.
I don’t know if anyone’s talking about it, but I’d really like to see generic constants, like int/bool template arguments in C++. As a mathematician, being able to write fixed-size arrays with reliable optimizations like loop unrolling with generic code would be fantastic. Perhaps as syntactic-sugar around same-type tuples with dynamic element access. SIMD is nice but sometimes one needs a bit more flexibility.
Perhaps arrays can be written like
var vec = (Float,4)
then one can have structs like
struct Vector {
var arr: (Float,D)
}
var vec = Vector()
This reflects the protocol syntax for generics, but extends to instantiable types that have compile-time constant representations. Someone better at designing languages can certainly come up with better syntax.
I’d love to see string literals and better support for regular expressions baked into the language rather than relying on heavily escaped strings. I assume this is something that can be added in a later Swift version without too much turmoil.
My current wish list is quite short :
Bring Set up to parity with Array and Dictionary by allowing it to store members of a protocol as well as concrete types and add a Swift OrderedSet while we are at it 🙂
OptionSetType – what a pain to use … In my current project, extracting an Array of Enum members from an OptionSetType, is the only place left in my code where I have been unable to easily replace ++
As in : bit shifting
Thanks Erica