Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

On 07/12/2016 10:40 AM, Andrei Alexandrescu wrote:
> On 07/12/2016 10:26 AM, H. S. Teoh via Digitalmars-d wrote:
>> On Tue, Jul 12, 2016 at 01:33:00AM -0400, Andrei Alexandrescu via
>> Digitalmars-d wrote:
>>> On 07/12/2016 01:15 AM, Shachar Shemesh wrote:
>> [...]
>>>> Casting away immutability is UB in D.
>>>
>>> I understand. There is an essential detail that sadly puts an
>>> anticlimactic end to the telenovela. The unsafe cast happens at
>>> allocator level.
>> [...]
>>
>> What's an "unsafe cast"?  I think we're mixing up terminology here,
>> which is not helping this discussion.
>>
>> Is casting away immutable merely *unsafe*, or is it UB?
>
> The subtlety here is that immutable is not being cast away. All data
> that is typed as immutable stays immutable. -- Andrei

To clarify, this is the code in question:

https://github.com/dlang/phobos/blob/master/std/experimental/allocator/building_blocks/affix_allocator.d#L210

The parameter is an array of a generic type T (which may be immutable). 
The immutability of data is not compromised; the pointer to the 
beginning of the array is only used as a pivot to access data that sits 
before the array. That data has never been typed as immutable, so the 
code is typed correctly (assuming the data had been allocated with this 
allocator), even though the compiler cannot prove it.

The language definition must allow this to work. But this is not a 
matter of changing the definition of immutable. It's a simple matter of 
data layout (e.g. if you add a positive number to a pointer and later 
you subtract it, you get the same pointer etc). We already have that 
down, even if the spec language could be better.


Andrei