[swift-evolution] [Idea] Allow more operators as custom operators

[Антон Жилин]

You can already define custom operator `<-`. I'm talking about tokens which
are reserved, but look like operators. For example,
postfix operator ! { }
is an error, which seems illogical, because optional force-unwrapping
totally looks like an operator.

2016-04-11 0:14 GMT+03:00 <hitstergtd+swiftevo at gmail.com>:

> How about "<-"?
>
> I could see a few shorthands with that for Strings, etc. :-)
>
> On 10 April 2016 at 22:03, Jean-Daniel Dupas via swift-evolution
> <swift-evolution at swift.org> wrote:
> >
> > Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution
> > <swift-evolution at swift.org> a écrit :
> >
> > & (as a prefix operator), ->, ?, and ! (as a postfix operator)
> >
> > This is the list of built-ins that look like operators, but are banned
> from
> > use as Swift custom operators.
> >
> > We can review that list.
> >
> > `&` reserved as a prefix operators for a reason. It marks a variable use
> as
> > `inout`, which currently cannot be done by any Swift operator function.
> >
> > Other three don't have such justification.
> >
> > `->`, `?` and `!` are used in types, but they are mostly unambiguous in
> > expressions.
> >
> > The only use of `!` in expressions can be rewitten as a built-in operator
> > function:
> > postfix func ! <T> (left: T!) -> T
> >
> > `?` is used in optional method calls:
> > a.method?(b)
> > A parallel proposal is going to remove such syntax from Swift, so this
> will
> > not be a problem.
> >
> > `?` is also used in patterns:
> > if case x? = optional { ... }
> >
> >
> > While the use is unambiguous for the compiler, I’m not sure it’s going
> to be
> > unambiguous for code readers. Having the same operator meaning different
> > things depending the context is a bad idea IMHO.
> >
> >
> > _______________________________________________
> > 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/20160411/ddc9ba7b/attachment.html>