[Idea] Allow more operators as custom operators


(Anton Zhilin) #1

& (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 { ... }

Such use is also unambigious here, as expressions are not allowed in
patterns.

So my proposal is to allow `->`, `?` and potfix `!` as custom operators.
This proposal requires proposal of removing optional protocol requirements.


(Jean-Daniel) #2

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.

···

Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution <swift-evolution@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 { ... }


(Brent Royal-Gordon) #3

`->`, `?` and `!` are used in types, but they are mostly unambiguous in expressions.

Sure, but types can appear in the middle of expressions. If we drop the `.self` requirement, a type name will *be* an expression. I don't think you can just ignore type names.

The only use of `!` in expressions can be rewitten as a built-in operator function:
postfix func ! <T> (left: T!) -> T

This doesn't work because you can assign through an `!`. For instance:

  numberDictionary[key]! += 1

Once we have inout return values, we might be able to make `!` a normal postfix operator. (Actually, the same goes for `&`, which just becomes a way to leverage the implicit `&`ing of operator arguments into an explicit `&`ing.)

`?` 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 used for a lot more than that in expressions: optional chaining, the ternary operator, etc. None of them can be expressed as ordinary operators without significantly expanding operator syntax.

Sorry, I don't think we can make any real progress in this space without additional language features.

···

--
Brent Royal-Gordon
Architechies


#4

How about "<-"?

I could see a few shorthands with that for Strings, etc. :slight_smile:

···

On 10 April 2016 at 22:03, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> wrote:

Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution > <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #5

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@gmail.com>:

How about "<-"?

I could see a few shorthands with that for Strings, etc. :slight_smile:

On 10 April 2016 at 22:03, Jean-Daniel Dupas via swift-evolution > <swift-evolution@swift.org> wrote:
>
> Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution > > <swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


(Anton Zhilin) #6

`!` 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@xenonium.com>:

Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution < > swift-evolution@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.


(Anton Zhilin) #7

Thank you Brent!
I forgot about the cases you described, where use of `->`, `!` or `?`
cannot be expressed as operator functions.
The question is closed now, I guess.

- Anton

···

2016-04-11 9:03 GMT+03:00 Brent Royal-Gordon <brent@architechies.com>:

> `->`, `?` and `!` are used in types, but they are mostly unambiguous in
expressions.

Sure, but types can appear in the middle of expressions. If we drop the
`.self` requirement, a type name will *be* an expression. I don't think you
can just ignore type names.

> The only use of `!` in expressions can be rewitten as a built-in
operator function:
> postfix func ! <T> (left: T!) -> T

This doesn't work because you can assign through an `!`. For instance:

        numberDictionary[key]! += 1

Once we have inout return values, we might be able to make `!` a normal
postfix operator. (Actually, the same goes for `&`, which just becomes a
way to leverage the implicit `&`ing of operator arguments into an explicit
`&`ing.)

> `?` 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 used for a lot more than that in expressions: optional chaining,
the ternary operator, etc. None of them can be expressed as ordinary
operators without significantly expanding operator syntax.

Sorry, I don't think we can make any real progress in this space without
additional language features.

--
Brent Royal-Gordon
Architechies