More D newb questions.

Steven Schveighoffer schveiguy at yahoo.com
Tue May 6 11:08:48 PDT 2008


"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> This is the only sound reasoning that you have, but it's not that adding 
>> the concat operator for basic types would break things, it's that adding 
>> it would be a redundant method of doing [T, T], which makes sense to me.
>
> It breaks things because concatenating two arrays is a very, very 
> different thing than forming a new array with two values in it. The 
> ambiguity comes when the value is an array type:
>
> typeof(t1~t2) makePair(T t1, T t2)
> {
>     return t1 ~ t2;
> }
>
> int[] a;
> char c;
>
> makePair(c,c);   // ok, I get an array with two elements, what I want
> makePair(a,a);   // I don't get a pair of arrays at all, big surprise

If you didn't want to be surprised, then don't make the return type based on 
what the concatenation operator returns.  It's much easier to write:

T makePair(T t1, T t2)

or

T[] makePair(T t1, T t2)

depending on what your intentions are.

I still don't see the issue.
Why can't the compiler do this:

T ~ T => T ~ T[0] ~ T

Same thing, no?

It seems that it is a natural reduction, one that has no ambiguity or causes 
issues with generic code.

> In other words, opCat for a struct means "concatenate the container 
> contents", not concatenate the struct value.

You are concatenating the struct contents, into a new array.  I don't see 
the ambiguity or the confusion it would cause.

In any case, I'm done debating this, because I don't think it matters 
anyways :)  The current language is sufficient to make arrays out of 
elements using the [T, T] syntax, so on that point alone, it is sufficient 
to reject this enhancement.  I just think your other points are invalid.

-Steve 





More information about the Digitalmars-d mailing list