Sent from my iPhone
On Dec 22, 2015, at 1:26 PM, Paul Cantrell via swift-evolution <[email protected]> wrote: >> On Dec 22, 2015, at 12:03 PM, Chris Lattner <[email protected]> wrote: >> >>>> On Dec 22, 2015, at 9:44 AM, David Owens II via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> On Dec 22, 2015, at 9:30 AM, Paul Cantrell via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> Hmm, I wonder if #1 or #4 suggest any language changes to propose for this >>>> list. >>> >>> Tangential to the topic at hand, but default values in tuples is something >>> I’ve wanted for a while. Comparing optionals in a case statement would also >>> be nice. >> >> If you dig through history, you’ll find that we had them at one point >> (perhaps even in the swift 1.x timeframe), and we even had varargs tuples. >> We removed both of them because they were infrequently used and adding a >> tremendous amount of complexity to the compiler (and were very buggy as a >> result). > > If you squint a little, tuples are just anonymous structs with limited > features. If you squint. > > One of my favorite features of Swift is how (at least at the semantic level) > it has no primitive types. Int is a struct! Brilliant! I’ve wondered on and > off (even before this list) if perhaps the language could eliminate another > fundamental type by making tuples just be sugar for structs. > > What would that look like? I am thinking out loud here… > Variadic generics would be a good start. See Tuple in C++. I like that you address pattern matching for structs here as well. > • Every tuple is secretly just an instance of an anonymous struct, much as > optionals are secretly just enums. > • Under the covers, functions all take a single struct argument and return a > single struct. > • Pattern matching can destructure structs. (Hmm, trouble here. Property > ordering in structs is suddenly significant in the API, not just the ABI.) > • The tuple syntax infers the type of the struct to be created, and can match > both named and anonymous structs … which it does by matching initializers, > whose arguments are a tuple, so … turtles all the way down? More trouble. > • The existing unwrapping of single-elem tuples is preserved, i.e. `let a: > (Int,Int) = (((((3))),3))` still works. > > All of this would mean that this: > > enum Doodad > { > case Doo > case Dad(name: String) > } > > …is equivalent to this (except for the introduction of the new “DadInfo” > identifier for what was previously anonymous): > > struct DadInfo > { > var name: String > } > > enum Doodad > { > case Doo > case Dad(DadInfo) > } > > …and thus this is a non-breaking change: > > struct DadInfo > { > var name: String > var punRating: JokeType = .Terrible > } > > enum Doodad > { > case Doo > case Dad(DadInfo) > } > > OK, so that’s an awful lot of squinting. It’s not clear that there’s an end > game here that makes sense. > > Cheers, > > Paul > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
