More D newb questions.

[Steven Schveighoffer]

"Walter Bright" wrote
> Derek Parnell wrote:
>> On Mon, 05 May 2008 14:16:02 -0700, Walter Bright wrote:
>>> T ~ T => T[]
>> Not quite. Only if T is not an array would this be the expectation.
>
> That means that it's an excessive burden on generic code to have to add an 
> extra test to ensure that T is an array type else lest unexpectedly 
> different code gets generated.

Not that I think this needs to be implemented, but your reasoning has gaping 
holes in it.

Currently, if you write a generic function:

T catTwoThings(T)(T t1, T t2)
{
   return t1 ~ t2;
}

Now, if I do:

catTwoThings!(char)('c', 'd');

The function fails.

If we added the ability to cat chars together like:

'a' ~ 'b' => "ab"

Then what happens to our poor generic function?  It still doesn't compile, 
because the return type isn't correct.  How is this any different than what 
we have today?  You still can't pass in chars to generic code that expect to 
use arrays.  How does that put an excessive burden on generic code?

>
> What do we do when T's a struct? Look inside the struct to see if it 
> overloads opIndex? I propose that that's an excessive complication with 
> little benefit, especially considering there's already unambiguous syntax 
> to create an array out of values:

What are you talking about?  The same thing exists with structs, the 
compiler wouldn't do any special inference, it just cares if there is a 
concatenation operator defined for the type.  Why does opIndex have anything 
to do with it?  In a struct you can have:

struct MyChar
{
   char c;
   MyChar[] opCat(MyChar x) { return [*this, x];}
}

Does this break all generic code?

> [T, T] => T[]
>
> So, we have the unambiguous syntax to create an array out of values, and 
> another unambiguous syntax to concatenate arrays:
>
> T ~ T => T

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.

>
> and we have an ambiguous syntax to append or prepend values to an array:
>
> T ~ T[] => T[]
> T[] ~ T => T[]
>
> I think there is no tern unstoned here.

I think you meant unambiguous :)

-Steve