[swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

[Paul Cantrell]

> On Dec 22, 2015, at 12:03 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> On Dec 22, 2015, at 9:44 AM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> On Dec 22, 2015, at 9:30 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/8cabd88c/attachment.html>