April 07, 2020
On Tue, Apr 07, 2020 at 07:52:36PM +0000, tsbockman via Digitalmars-d wrote: [...]
> The problem in the language is that immutability is considered a permanent and fundamental property of a value, whereas it is actually a state that is entered after the initialization/construction of the value is complete, and exited when the value's memory is later reclaimed.
> 
> Construction of an immutable value should be done by making a mutable variable, mutating it to the desired state via any arbitrary sequence of normal operations, and then declaring the mutable stage of its life cycle complete via `cast(immutable)` or something. The only problem with this is making the compiler smart enough to prove that no mutable references to the data are used after that point, so that the operation can be @safe.
[...]

Actually, in the current language if you have a pure function that constructs a (mutable) value of type T, and the compiler can infer that the function returns a unique value, you can implicitly cast it to immutable:

	struct T {
		int x;
		float[] y;
	}
	T makeT(int x, float[] y) pure {
		return T(x, y);	// N.B.: returns mutable
	}
	void main() {
		// N.B.: no need to cast:
		immutable(T) t = makeT(1, [ 2.3, 4.5 ]);
	}


T

-- 
Chance favours the prepared mind. -- Louis Pasteur
April 08, 2020
On Tuesday, 7 April 2020 at 19:52:36 UTC, tsbockman wrote:
> On Tuesday, 7 April 2020 at 14:15:20 UTC, FeepingCreature wrote:
>> Right, but that's still the exact same workaround, except with Nullable instead of Algebraic. I know how to work around it. I'm saying what should be changed in the language so I don't *have to* work around it?
>
> The problem in the language is that immutability is considered a permanent and fundamental property of a value, whereas it is actually a state that is entered after the initialization/construction of the value is complete, and exited when the value's memory is later reclaimed.
>
That sounds like a way of thinking that can't be compatible with something like `immutable struct S {}`? Because https://issues.dlang.org/show_bug.cgi?id=20670 aside, S can't really be in a "mutable state", typewise.
April 09, 2020
On Friday, 3 April 2020 at 06:56:27 UTC, FeepingCreature wrote:
> Maybe D could allow to initialize an immutable variable from the try{} body if the catch{} body is statically known to exit by return/throw?

Sounds like making try an expression:

immutable struct S { }
...
S s =
  try
    fun(); // implicit result
  catch (Exception)
    return;
call(s);

The above could also work if the catch block had the result and the try block was a terminating statement.

Another option would be a new expression that either yields the first expression if no exception was thrown, or it catches the exception and executes a statement or block that must terminate:

S s = fun() __or_catch (Exception e) return;
call(s);

(I have seen a similar form of expression for unwrapping optional values, terminating if the value doesn't exist in V language).

Not sure whether these are worth having yet as I've only just considered them ;-)
1 2
Next ›   Last »