> 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…
• 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
