> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
