equivariant functions

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Oct 14 10:07:44 PDT 2008


KennyTM~ 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);
>>
>> I think this could work and doesn't look half bad. Of course, you'll 
>> be tasked with addressing protests about yet another D1/D2 
>> incompatibility. :o)
>>
>>
>> Andrei
> 
> I'm afraid the meaning of inout here is very unclear without explanation.

I think more explanation is needed for the other case:

inout(char)[] stripl(inout(char)[] s);

What if I pass a const char[]? Is that going to work? In contrast, this 
is simple:

inout stripl(inout const(char)[] s);

Accept and return any subtype of const(char)[].


Andrei



More information about the Digitalmars-d mailing list