array of elements of various sybtypes
denis.spir at gmail.com
Fri Jan 28 10:55:26 PST 2011
On 01/28/2011 04:53 PM, Steven Schveighoffer wrote:
> On Thu, 27 Jan 2011 08:33:05 -0500, spir <denis.spir at 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 at gmx.com>
>>>> On Wednesday 26 January 2011 18:59:50 Steven Schveighoffer wrote:
>>>>> On Wed, 26 Jan 2011 18:28:12 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
>>>>> I'd like to see cast(T0)[...] work, I think that should solve the
>>>> It probably doesn't for the exact same reason that the assignment didn't do
>>>> 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.
vita es estrany
More information about the Digitalmars-d-learn