On Tuesday, 16 September 2014 at 06:27:59 UTC, Klaus wrote:
>
> is just a horrible way of shortcuting the static typing. You write this thinking that i "has to be..." and then you complain latter because the cast does not work.
> D is a strongly typed lang. in your example you use "auto" because your brain doesnt give you what the type of i has to be, which is an error. D is not a scripting lang. You made a wrong usage of "auto".

Admittedly this came about as a result of some poor design on my part, but I don't get what you're saying about auto. I thought auto was supposed to relieve the cognitive load of manual type identification. Without it, std.algorithm would be a pain to use. My brain doesn't intuitively tell me that std.algorithm.filter returns a FilterResult, but I can use it effectively with auto.

On Tuesday, 16 September 2014 at 11:26:05 UTC, rcor wrote:
> On Tuesday, 16 September 2014 at 08:49:04 UTC, Marc Schütz wrote:
>> On Tuesday, 16 September 2014 at 08:39:43 UTC, Marc Schütz wrote:
>
>>
>> Whether the compiler should accept that or not is a different question. I guess it should, because if it doesn't, there wouldn't be an easy way to achieve a reinterpret cast (only via an intermediate cast to `void*`, which is clumsy).
>>
>> Anyway, using `std.conv.to` is the way to go here (if you don't require that last bit of performance), because it is safer in general (also checks for overflows and the like, for example).
>
> Thanks, didn't think of trying std.conv.to. Can someone expand a bit on what to! is doing in this situation that cast isn't? I looked up 'reinterpret cast' but didn't see the connection to this.

Reinterpret cast means that the compiler should treat whatever is at the memory location as the given type, and not modify it in any way. `std.conv.to` can do more work, for example it can also parse strings into integers:

    assert("42".to!int == 42);

>
>>
>> AFAIK casting between interfaces and classes needs to adjust the underlying pointer. Therefore, when casting an array, the compiler would have to do that with the entire array, which cannot be copied without allocating memory (and mustn't be modified in-place for consistency reasons). This means that the cast is instead a pure reinterpret cast (repainting).
>
> Is to! creating a new array of pointers while cast isn't? This isn't a performance critical section and it's not a huge array, so I ask mostly out of curiosity.

Yes, it is. (Probably. I don't have the time to test it now, but it's likely if my theory about the pointer adjustment is correct.)

On Tuesday, 16 September 2014 at 14:13:48 UTC, Marc Schütz wrote:
> On Tuesday, 16 September 2014 at 11:26:05 UTC, rcor wrote:
>>
>> Is to! creating a new array of pointers while cast isn't? This isn't a performance critical section and it's not a huge array, so I ask mostly out of curiosity.
>
> Yes, it is. (Probably. I don't have the time to test it now, but it's likely if my theory about the pointer adjustment is correct.)

I guess I could have checked that out myself:

import std.stdio;
import std.conv;

interface I {}
class C : I {}
class D : I {}

void main() {
  C[] c = [new C, new C];
  I[] i = cast(I[]) c;
  I[] i2 = c.to!(I[]);
  assert(c is cast(C[]) i);    // i and c point to same address
  assert(i !is i2);            // to! appears to create a new array
}