[swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

[Xiaodi Wu]

I too have a little trouble with the suggested trampoline syntax:

>  static prefix func ++(value: inout Self) -> Self
>  static postfix func ++(value: inout Self) -> Self

I agree with Brent that the most appropriate way to write the trampoline
itself would be something more like:

```
static func ++ (prefix value: inout Self) -> Self
```

No particular need to eliminate declaration modifiers altogether quite yet
for the non-trampoline operators. The reasoning is this: a "prefix func" or
a "postfix func" would be used at the call site by actually prefixing or
postfixing the value. By contrast, the trampoline functions are called like
any other static member -- i.e. `T.++(prefix: foo)` -- and thus the
function itself is not really a "prefix func" or a "postfix func", just a
func with a parameter label.


On Tue, May 17, 2016 at 9:57 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > Additionally, I am generally +1 for the same reasons as Brent, but I
> > have another caveat as well:
> >
> > Defining prefix and postfix functions looks like this in the proposal:
> >
> >  static prefix func ++(value: inout Self) -> Self
> >  static postfix func ++(value: inout Self) -> Self
> >
> > yet the proposal suggests calling them this way from these boilerplate
> > methods:
> >
> > prefix func ++ <T: SomeProtocol>(value: inout T) -> T {
> >  return T.++(prefix: &value)
> >  }
> > postfix func ++ <T: SomeProtocol>(value: inout T) -> T {
> >    return T.++(postfix: &value)
> >  }
>
> I actually found this bizarre too, but forgot to mention it. My suggested
> solution runs in the other direction: We should require that *all* unary
> operator declarations and references use `prefix` or `postfix` as a
> parameter label. Thus, the trampoline operators themselves would be written
> as:
>
>         func ++ <T: SomeProtocol>(prefix value: inout T) -> T {
>             return T.++(prefix: &value)
>         }
>
>         func ++ <T: SomeProtocol>(postfix value: inout T) -> T {
>             return T.++(postfix: &value)
>         }
>
> Not would be written as:
>
>         func ! <B: BooleanType>(prefix value: B) -> Bool
>
> While force-unwrap (if we had inout return values) would be written:
>
>         func ! <T>(postfix value: inout Optional<T>) -> inout T
>
> `prefix` and `postfix` would be eliminated from the language as
> declaration modifiers, except when declaring custom operators (which is
> already the Land Of Ad-Hoc Syntax).
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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/20160517/0c7de6d0/attachment.html>