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

[Brent Royal-Gordon]

> 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