[swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Wallacy]

"In the context of this proposal, I think of backticks as delimiters around
a generalized name. It's a generalization of today's notion that it's an
escaped identifier; more like an escaped name."

backticks are just a "hack", with the proposal 0001 (Allow (most) keywords
as argument labels),  your proposal, we just will not see this feature
being used.

It's not just a matter of style, just does not seem natural.

Expand type annotation to "pick" the correct function, as I said before,
seems to me more natural. Or choose another symbol of course.

Em seg, 28 de dez de 2015 às 17:49, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> escreveu:

>
>
> Sent from my iPhone
>
> > On Dec 27, 2015, at 8:34 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >>> On Dec 27, 2015, at 4:27 PM, John McCall <rjmccall at apple.com> wrote:
> >>>
> >>> On Dec 27, 2015, at 4:15 PM, Chris Lattner <clattner at apple.com> wrote:
> >>>
> >>> On Dec 27, 2015, at 4:09 PM, John McCall <rjmccall at apple.com> wrote:
> >>>>> I’m a fan of good error recovery, but I don’t think it is a major
> concern here for two reasons:
> >>>>>
> >>>>> 1) The most common case in a method will lack a label, and
> "thing.foo(_: “ and “thing.foo(:” are both unambiguously a curried
> reference.
> >>>>> 2) A common case of accidentally completing a nullary call
> (thing.foo() vs thing.foo) will produce a type error.  We already produce
> good QoI for an unapplied function - adding the inverse would be simple.
> >>>>>
> >>>>> Further, it will be uncommon *in general* to form a curried
> reference, so error recovery doesn’t have to be perfect in all the edge
> cases.  As with other commenters, if it is at all possible to avoid the
> extra backticks, I’d really prefer that.
> >>>>
> >>>> The concern, I think, is that a messed-up normal call might look like
> a curried reference.
> >>>>
> >>>> My inclination would be to go the other way: if we get a syntax for
> this that we like, I think we should use it for *all* curried member
> references, and reject things like foo.bar in favor of foo.`bar`.  The
> ability to write foo.bar for a method has always struck me as more clever
> than wise, to be honest.
> >>>
> >>> If you were to go that far, I’d suggest looking at this as a different
> version of the “." operator.  If you resyntax curried to something else
> like (just a strawman, intentionally ugly syntax):
> >>>
> >>>    foo.#bar
> >>>
> >>> Then you’d get a nice property that the plain old dot operator always
> has to be fully applied.  This certainly would be a win for error
> recovery.  Also, if you did this, you wouldn’t need the backticks from
> doug’s proposal either for things like:
> >>>
> >>>    foo.#bar(param1:param2:)
> >>>
> >>> either.
> >>
> >> Right.  I really like this effect.
> >>
> >> I’m not that bothered by requiring the backticks, especially because it
> generalizes well to non-member function references, which I’m not sure any
> sort of different-member-access syntax does.
> >
> > I’m bothered by it because it overloads backtick to mean two things:
> keywords-as-names, and annoying-sequences-of-tokens-as-names.  Either use
> would be acceptable to me, but the fact that we have to support one nested
> inside the other makes it pretty nasty.
>
> In the context of this proposal, I think of backticks as delimiters around
> a generalized name. It's a generalization of today's notion that it's an
> escaped identifier; more like an escaped name.
>
> > -Chris
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151228/6d5069be/attachment.html>