@safe inference fundamentally broken

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 5 13:37:51 PDT 2014


On Thu, 05 Jun 2014 16:32:24 -0400, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Thursday, 5 June 2014 at 19:57:08 UTC, Steven Schveighoffer wrote:
>> A possible fix could be to reject the call to ptr at runtime if the  
>> slice is empty.
>
> I don't know why you'd ever do "arr.ptr" in the first place, other than  
> to avoid the bounds check. So I think the call should just be unsafe,  
> and we call it a day. Or maybe to interface with a function that want a  
> pointer?

That's true. You can always get a pointer to any valid element with  
&arr[x]. Then at least you have bounds checking to save you.

In fact, in safe code, arr.ptr could be replaced with &arr[0].

> "Maybe", we could get away with allowing "&arr[someIndex]" though. The  
> compiler would have to be able to "understand" this is not escaping a  
> reference (for *DYNAMIC* arrays anyways).

If we are going to allow pointers, we need to allow pointers to data we  
know is valid and heap-allocated. This should include dynamic array  
elements.

-Steve


More information about the Digitalmars-d mailing list