equivariant functions

[David Gileadi]

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