equivariant functions

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>>> Steven Schveighoffer wrote:
>>>> "Andrei Alexandrescu" wrote
>>>>> I discussed with Walter a variant that implements equivariant 
>>>>> functions without actually adding an explicit feature to the language. 
>>>>> Consider:
>>>>>
>>>>> typeof(s) stripl(const(char)[] s);
>>>> As another point on this, I think someone else mentioned it, but I 
>>>> can't find the post.
>>>>
>>>> I don't like the way this looks.  The way it reads is 'stripl returns 
>>>> the same type as s', but really, the typeof(s) is actually modifying 
>>>> the type of the argument also.  This seems very unintuitive.
>>> I agree. We need to look for a better notation.
>>>
>>>> I understand the need to not change the language, but I think most 
>>>> would prefer a syntax where the type modifier is specified on at least 
>>>> the argument.  People are going to be extremely confused when they 
>>>> can't treat 's' like a normal const(char)[].
>>>>
>>>> If the ultimate result is that no intuitive syntax can be made without 
>>>> changing the language, then I think it is more important to have this 
>>>> feature than to not change the language.
>>>>
>>>> One other syntax that Janice proposed (and I later put into a 
>>>> bugzilla), is to use the dead keyword inout.  Meaning, what you send in 
>>>> is what you get out.  ref already completely replaces inout, so there 
>>>> is no need to keep it under its current meaning:
>>>>
>>>> inout(char)[] stripl(inout(char)[] s);
>>>>
>>>> I'm not in love with this completely, but it has the benefit of not 
>>>> requiring a new keyword.
>>> Also I guess:
>>>
>>> class C
>>> {
>>>     Range!(inout(C)) foo() inout;
>>> }
>>>
>>> And also:
>>>
>>> class Base {}
>>> class Derived : Base {}
>>> inout foo(inout Base b);
>>
>> In this last example, what does the inout mean at the front?
>
> Accept and return any subtype of Base.

so in this case, inout is equivalent to inout(Base)?  Definitely a nice 
idea, since it can always be implied.  But this makes it look very weird if 
the function is a member:

class X
{
   inout inout foo();
}

Where the first inout is a modifier on the 'this' argument, and the second 
inout is equivalent to inout(X).

Unless Walter is ok with abolishing the ability to put this modifiers at the 
front of member functions? :D

-Steve