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 <[email protected]>: > 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 > <[email protected]> wrote: > > > > Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution > > <[email protected]> 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 > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
