array cast should be supported corrected

Steven Schveighoffer schveiguy at yahoo.com
Fri Aug 8 07:17:48 PDT 2008


"Robert Fraser" wrote
> Steven Schveighoffer Wrote:
>> O(1) aliasing is OK for a base class if you
>> are not planning on changing the existing elements.
>
> In this case it should require an explicit cast. A[] could be implicitly
> castable to const(Base[]) but not to const(Base)[] or Base[].

That eliminates the possibility of having covariant functions that return 
arrays of objects.

>> > It's also extremely easy to overlook this error. Say you're passing an
>> > array
>> > of A[] to a function that modifies an array of Base[] by possibly 
>> > adding
>> > things. In a large system, it can be a tricky bug to track down since 
>> > the
>> > error may not manifest itself until a while after it happens, and may 
>> > not
>> > always be a segfault (if they're the same size & it's just the bits 
>> > being
>> > interpreted as the wrong type, things could get very ugly -- it may not
>> > always just segfault).
>>
>> This is not a common case (to pass in a abstract base array in which you
>> plan on changing elements).  The common case is to use the base class 
>> array
>> as a means of writing a common function that *uses* the array, but does 
>> not
>> create elements in it.  For that, the cast is perfectly safe.  Or to use 
>> it
>> as a co-variant return value.  I think the benefits of being able to cast
>> this way outweigh the uncommon pitfalls.
>
> I agree the advantages are enough to justify allowing aliasing without
> serious subversion of the type system. But the cast _must be explicit_,
> so users see a red flag there. It's potentially dangerous, since you
> might accidentally interpret  one bit pattern as a different type. Short 
> of
> unions, only a cast can do that.
>
>> I look at it no differently than doing:
>>
>> class C {int x;}
>>
>> C c;
>> c.x = 5; // segfault
>
> How is that at all the same? In the case of implicit base class casting,
> you're tricking the compiler (likely without meaning to) into interpreting
> the data as an incorrect type. In this case, the compiler is acting 
> correctly
> and you have a bug in your code.

I'm trying to show that there is a precedent of being able to make code that 
fails without explicit casting.  Everyone knows that the 'right' thing to do 
is to create a new object before using it.

I could say exactly the same thing about your example.  The compiler is 
acting correctly and you have a bug in your code.

-Steve 





More information about the Digitalmars-d mailing list