On 12.04.20 04:26, Timon Gehr wrote:
> On 11.04.20 03:19, Victor Porton wrote:
>> ...
>>
>> int x = 1;
>> f(cast(*immutable(int*)&x);

Typos, I meant to write `f(*cast(immutable(int)*)&x)`.

>> x = 2; // the immutable reference does not exist at this point
>>         // but the assignment is disallowed(?)
> 

On 11.04.20 03:26, Adam D. Ruppe wrote:
> On Saturday, 11 April 2020 at 01:19:29 UTC, Victor Porton wrote:
>> Why this is disallowed?
> 
> Immutable means it NEVER changes. If you want it to just temporarily not change, that's what const is for.

No. `const` is for data that may or may not change at any time, just not by accessing it through that `const` reference. He is absolutely right that the rule is weird.

On 4/11/2020 7:26 PM, Timon Gehr wrote:
> According to spec I think it's invalid, therefore it is impossible to manually manage immutable memory. I think the specification should rather be something along the lines that it is undefined behavior to read different values using the same (logical) reference to immutable data.

I've made a start on defining lifetimes in the spec, but it's hard to turn "I know what I mean" into legalese.

I also wish to carefully avoid crafting semantics that require Data Flow Analysis to implement. It does turn out to be necessary to do DFA for @live, but at least that's optional.

This is why, for example, the language uses lexical closures to determine where to insert destructors rather than "last use".

On 4/11/2020 7:30 PM, Timon Gehr wrote:
> the rule is weird.

The rule is a consequence of not requiring Data Flow Analysis to diagnose whether a mutable reference outlives it and is used.

On 12.04.20 22:39, Walter Bright wrote:
> On 4/11/2020 7:30 PM, Timon Gehr wrote:
>> the rule is weird.
> 
> The rule is a consequence of not requiring Data Flow Analysis to diagnose whether a mutable reference outlives it and is used.
> 

?

The compiler is not even expected to diagnose wrong casting.