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

[Kevin Lundberg]

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
>