-1 It took awhile to catch up. I understand the motivation but don't agree with the solution. The suggested proposal adds language complexity that can hopefully be solved in other ways.
In catching up I related to Howard Lovatt's response. Jordan responded: > On Dec 20, 2017, at 2:33 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > I find it interesting that you call this the "unsafe" case. From my point of > view <https://imgur.com/4OWRavD>, it is very much in line with Swift's > current design to have the default be "force clients to consider all > possibilities" (like Optional), as well as "let library authors decide what a > client should be able to rely on" (like 'open'). I don't understand this. Optional is exhaustive. What you're describing is more like Swift error handling, which is quite different and much more cumbersome in use. > This is an interesting point that I probably should have expanded more in the > "comparison with other languages" section. Swift has protocols too, and you > can build most of the features of enums with protocols. (Set aside the > inferior pattern-matching for now; that's something we could add to Swift.) > This is currently much more heavyweight than enums, but let's roll with it. > > Next we have to deal with C enums, which can have "private cases" or > newly-added cases. Okay, maybe those get imported as structs instead, like > NS_OPTIONS. That's not too bad, is it? > > Now we're back in a place where 'enum' always means "exhaustive". That's > good, right? Except…now we have a kind of type where the recommendation will > be "don't use these in your library's public API; they'll be stuck that way > forever", a trap waiting for library authors. That's a problem C has with > structs, and it's something we don't want to bring into Swift. Making a > library necessarily requires more care than making an app, but we don't want > there to be techniques that only make sense within a module, and are > discouraged when writing a library. > > So we can implement this world in Swift. I just don't think it'll be a better > one. When someone makes a library, the default should be safe for them. That > means that they reserve the ability to add cases, and also to make the enum > "exhaustive" in the future if it turns out that's the right thing to do. > > (You're free to continue to disagree with me on this; thanks for getting me > to write it out.) I don't think the default third-party library case mirrors Foundation and UIKit (and authors that provide libraries like that must take more care in general and don't require extra language sugar that benefits just them). There are plenty of library authors whose default case is: when you upgrade to use our latest version, you need to consider all added cases, as it's source-breaking. I think this is far more common than the well-kempt releases Apple shepherds through each year. I don't think we should lose our primitive type that always requires exhaustive switching, and I don't see the need to overcomplicate the language when we already have at-hand solutions (like extensible structs). If we're worried about library authors falling into the trap of misusing enums, we should provide a better mechanism for declaring raw-representable (or similar) entities, via something like NS_RAW_REPRESENTABLE, compiler magic, and/or a hygienic macro system. I'd also like to point out that the current state of Swift development requires frameworks separate from the app: 1. If you want to import code into a playground. Playgrounds are a celebrated form of code demonstration, but app executable code cannot run in a playground. It needs to be extracted to a framework first. 2. SPM executables cannot run tests or have test targets. Testable SPM code needs to be extracted to a framework. If you want to test your code, it needs to be in a framework. Both cases above affect app developers that aren't necessarily in the library biz. It's not great if the default for them is enums that suddenly become non-exhaustive. Stephen
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
