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

[Xiaodi Wu]

I think we don't need to invoke special compiler behavior. Namely, since
the trampoline is manually generated, do this:

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

Later:
```
postfix func ++ <T: SomeProtocol>(value: inout T) -> T {
  return T.++(anyLabelYouWant: &value)
}
```

On Tue, May 17, 2016 at 10:57 PM, Kevin Lundberg via swift-evolution <
swift-evolution at swift.org> wrote:

> I do like this to a point, but it ascribes special compiler behavior to
> specific argument labels which feels odd. If someone defined another
> operator function with a completely different argument label, would it just
> be ignored? If a developer makes a typo, that could be a subtle bug that
> may be confusing. Or should the compiler only allow those two argument
> labels for unary operator functions? That feels strange since it's not a
> restriction present anywhere else, and it starts to feel like the labels
> have a dual purpose that also falls into the realm of keywords.
>
> Either option doesn't quite sit right with me, even though the lack of
> duplication that this solution has does look better, admittedly.
>
> --
> Kevin Lundberg
>
> On May 18, 2016, at 12:57 AM, Brent Royal-Gordon <brent at architechies.com>
> 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/d09f261a/attachment.html>