equivariant functions

Simen Kjaeraas simen.kjaras at gmail.com
Tue Oct 14 11:38:58 PDT 2008


On Tue, 14 Oct 2008 18:51:56 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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.
>
> Andrei

I was first wondering how this would treat things like

   inout foo(Base b, int n);

But then I noticed it saying "inout Base b", so only the argument(s) marked
inout are considered for the return type? Also, this means a maximum of one
inout argument type per function, right?

As for the keyword, I feel inout is better than typeof, and good enough.  
Not
perfect, but good enough.

-- 
Simen



More information about the Digitalmars-d mailing list