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

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

`!` is already a de-facto postfix operator and is called optional
force-unwrapping.
Although it is currently defined not as an operator function, but, oddly
enough, as a special case in Swift grammar.
There are more things that may deserve this operator: for example,
Result<T, E> would force-return T.

Operator `->` (Arrow) would find a great use in functional programming
libraries (hello Haskell lovers).

As for operator `?`, it can be used to turn some custom type into optional.
For example, Result<T, E> into Optional<T>.

I would also argue that such operators are unambiguous to their users.
If you define such custom operators and add operator functions for them,
then you definitely know what they mean for you.

- Anton

2016-04-11 0:03 GMT+03:00 Jean-Daniel Dupas <mailing at xenonium.com>:

>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160411/af32bc9c/attachment.html>