> 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