equivariant functions

[Denis Koroskin]

On Tue, 14 Oct 2008 23:17:18 +0400, David Gileadi <foo at bar.com> wrote:

> Steven Schveighoffer wrote:
>> "KennyTM~" wrote
> [snip]
>>> By the explanation argument, I actually mean what a programmer first  
>>> sees this feature think of. Presented with Andrei's "typeof" syntax, I  
>>> can at least guess what the function looks like (it returns the same  
>>> type as "s", OK)
>>  Then you failed to see the true meaning of Andrei's syntax ;)  It  
>> means that the return value is the same as what you used as s to call  
>> the function, not the type of s (which is whatever the function  
>> declares s as).  The return type changes depending on what you call it  
>> with.
>>  e.g.:
>>  typeof(s) foo(const(char)[] s);
>>  ....
>>  char[] x = "hello".dup;
>>  auto x2 = foo(x); // x2 is typed as char[], even though s is declared  
>> as const(char)[]
>>
>>> ; but with "inout" I just stopped with "What the heck is going on?!".
>>  At least you are not guessing the wrong thing.  This would probably  
>> prompt you to look up how inout works in the docs.
>>  I'm not saying that inout is the ideal keyword.  I'm saying that this  
>> is a novel enough concept that probably people are not going to  
>> intuitively see what is going on no matter what keyword is used.  They  
>> have to learn what it's doing by reading docs.  Using typeof as Andrei  
>> defined seems intuitively to mean something entirely different, and  
>> most likely will not prompt a lookup of the docs (until it doesn't  
>> behave as expected).  Plus it doubles the meaning of yet another  
>> keyword, which I hate...
>>  e.g. what did you think was happening when you first saw 'mixin'?  Did  
>> you intuitively think 'oh, this must take what I give it as a  
>> compile-time generated string and compile it into actual code'.   
>> Probably not, so is mixin a bad keyword choice for that feature because  
>> you didn't intuitively think of it?
>>  -Steve
>
> FWIW I agree with KennyTM~ here--typeof(s) made sense to me, including  
> its meaning that you describe above.  This, even though it conflicts  
> with the keyword's current meaning.  I suppose it's because "typeof(s)"  
> could stand for "some type of s", i.e. some child type of s.
>
> The thing that concerns me about using typeof(s) is your earlier comment:
>
>> 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)[].
>
> -Dave

Using typeof, expression would get way too complex and involve some magic  
template trickery like PassQual!() to pass constancy qualifiers from one  
variables to another.
Besides, typeof proved to be insufficient to solve the problem:

typeof(t1) min(T)(T t1, typeof(t1) t2);

T t1 = ...;
auto t2 = ...;

auto t3 = min(t1, t2); // what is the type of t3? Is it T per typeof(t1)?
// Answer is - it depends.. on t2:

T t1 = ...;
const(T) t2 = ...;

auto t3 = min(t1, t2); // typeof(t3) == const(T)