On 01/28/2011 04:53 PM, Steven Schveighoffer wrote:
> On Thu, 27 Jan 2011 08:33:05 -0500, spir <denis.spir@gmail.com> wrote:
>
>> On 01/27/2011 05:05 AM, Steven Schveighoffer wrote:
>>> On Wed, 26 Jan 2011 22:10:58 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
>>> wrote:
>>>
>>>> On Wednesday 26 January 2011 18:59:50 Steven Schveighoffer wrote:
>>>>> On Wed, 26 Jan 2011 18:28:12 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
>>>>>
>>>>>
>>>>> I'd like to see cast(T0[])[...] work, I think that should solve the
>>>>> problem.
>>>>
>>>> It probably doesn't for the exact same reason that the assignment didn't do
>>>> it.
>>>> The expression is evaluated and _then_ it's cast. So, if the expression isn't
>>>> valid in and of itself, it fails.
>>>
>>> This works:
>>>
>>> cast(ubyte[])[1,2,3] // creates an array of 3 ubytes
>>>
>>> So clearly cast has an effect on the type of the array literal in that case.
>>> I'm not sure why this works and the other doesn't,
>> [1,2,3] is valid! [t1,t2] is not if one of the elements' type is not
>> implicitely convertible to the other. In your example cast applies to an
>> already constructed array. (Hope you see what I mean)
>
> I do, but what do you think the binary value of the array is? You might be
> surprised that it is
>
> 01h 02h 03h
>
> instead of the binary representation of the int[] [1, 2, 3]:
>
> 01h 00h 00h 00h 02h 00h 00h 00h 03h 00h 00h 00h
>
> i.e. all the elements are casted to ubyte *before* the array is constructed.
> This is the behavior I think we should have in all cases.

Are you sure of that? I mean that a cast of the /array/ literal actually casts its elements /during/ array construction? not afterwards, once an initial valid array is constructed.
Anyway, this may well be, for optimisation. But even then, there is still a semantic issue that in
	cast(T[])[e1, e2, e3...]
[e1, e2, e3...] must be semantically valid according to current D rules /prior/ to casting. And in the example [t1,t2] is not valid.

Unless we really change the language's syntax to make a cast operation prefixed to a literal actually be /part/ of the literal. In other words
	cast(T[])[e1, e2, e3...]
would have the sense of what I proposed to write in another post:
	[e1, e2, e3...]T
(by analogy with string postfixes)
This is a big change, i guess!

>>> but we definitely need
>>> something that allows one to control the array type of a literal.
>>
>> Yop! But this hint has to belong to the literal notation syntax itself. Not
>> anything (like cast ot to!) that applies afterwards.
>
> IMO cast is fair game, because it's a compiler internal operation. to! is a
> library function, and should not affect the literal type.
>
>>> In D1, the array could be typed by casting the first element (the first element
>>> was always used as the type of the array). In D2 we no longer can control the
>>> type of the array that way, we need some way to do it.
>>
>> Works in D2. If any element is of the inteded common type, then all goes fine.
>
> But this doesn't work to "force" the array type. It only works to force a
> different type into consideration for the common type.

Yes! Not the same thing...

> It is specifying a different intention to the compiler than I think you want.
> If, for example, you *wanted* the type of the array to be T0[], and not
> Object[], this line still results in an Object[] array:
>
> Object o = new T1;
> auto arr = [cast(T0)t1, t2, o];
>
> So wouldn't you rather the compiler say "hey, o can't be a T0, even though you
> want a T0[]" or would you rather it just happily carry out your order and fail
> later when you try T0 methods on any of the elements?

You are right, Steve! In some cases, casting an element does not have the side-effect I had in mind.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com