@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