I've read the pitch, but it isn't clear what the ask is or what benefit it would give. On Wed, Feb 22, 2017 at 8:05 AM Haravikk via swift-evolution < [email protected]> wrote:
> > On 22 Feb 2017, at 11:48, Brent Royal-Gordon <[email protected]> > wrote: > > On Feb 22, 2017, at 3:32 AM, Haravikk via swift-evolution < > [email protected]> wrote: > > foo.example(foo) // What did I mean here? > let result = foo.example(foo:) // This looks like I might be trying to > select a function, rather than call it > > > I think it would be really weird to support not one, but *two* potentially > ambiguous sugar forms. > > > Those aren't examples I think should be supported, I was thinking out > loud. The point I was trying to make is that it's not the trailing nature > that's a requirement, but that the real requirement for this feature to > work is that there's at least one other, non-Void argument. > > > On another note, one other alternative I did think of for declaration is > that perhaps it might be better still to use an attribute to specify a > label-only "argument". Think of it like an attribute on the type, except > that it specifies that there is no type: > > func adding(_ other:Self, reportingOverflow:@labelonly) { … } > > The attribute makes it absolutely clear that this is just a label and not > an actual, functional argument (there won't be a reportingOverflow local > variable), and that it can be passed without a value when calling this > method. It'll still need the trailing colon for possible disambiguation of > variables though. > _______________________________________________ > 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
