I've adapted my previous DIP on lazy initialization to make it usable for logical immutability, as is useful for reference counting, among other things:

http://wiki.dlang.org/DIP89

On Sunday, 21 February 2016 at 15:03:39 UTC, Marc Schütz wrote:
> I've adapted my previous DIP on lazy initialization to make it usable for logical immutability, as is useful for reference counting, among other things:
>
> http://wiki.dlang.org/DIP89

BTW the Usage section still uses lazy. I think the RCObject code shouldn't use new to construct the struct here:

auto o = new immutable(RCObject);

It probably needs to be on the stack instead.

(I also made a minor edit for formatting/readability, hope that's OK).

On Sunday, 21 February 2016 at 18:19:35 UTC, Nick Treleaven wrote:
> BTW the Usage section still uses lazy. I think the RCObject code shouldn't use new to construct the struct here:
>
> auto o = new immutable(RCObject);
>
> It probably needs to be on the stack instead.
>

Thanks, fixed.

> (I also made a minor edit for formatting/readability, hope that's OK).

Sure :-)

On Sunday, 21 February 2016 at 15:03:39 UTC, Marc Schütz wrote:
> I've adapted my previous DIP on lazy initialization to make it usable for logical immutability, as is useful for reference counting, among other things:
>
> http://wiki.dlang.org/DIP89

From the DIP:

> The second rule (@system) prevents accidental accesses that violate [logical const-ness]

It seems we could use @mutable as a method attribute instead of @trusted const. The advantage would be that code is still checked for @safety. Requiring it still helps to prevent unintentional mutation and remind the programmer about correct logical const encapsulation. I realise @trusted has more impact but really here this use isn't related to memory safety, (or is it)?

> static make() {

The return type is missing for the make() function:

On Monday, 22 February 2016 at 17:28:03 UTC, Guillaume Chatelet wrote:
>> static make() {
>
> The return type is missing for the make() function:

I'm pretty sure static here works just like 'static auto'. In D I think you can use storage classes (and even attributes) to imply auto:

const foo(){return 5;}

assert(foo() == 5);

On Monday, 22 February 2016 at 18:03:03 UTC, Nick Treleaven wrote:
> On Monday, 22 February 2016 at 17:28:03 UTC, Guillaume Chatelet wrote:
>>> static make() {
>>
>> The return type is missing for the make() function:
>
> I'm pretty sure static here works just like 'static auto'. In D I think you can use storage classes (and even attributes) to imply auto:
>
> const foo(){return 5;}
>
> assert(foo() == 5);

Ha right indeed it's probably going to work. It was just a bit surprising.

On 22.02.2016 19:03, Nick Treleaven wrote:
> On Monday, 22 February 2016 at 17:28:03 UTC, Guillaume Chatelet wrote:
>>> static make() {
>>
>> The return type is missing for the make() function:
>
> I'm pretty sure static here works just like 'static auto'. In D I think
> you can use storage classes (and even attributes) to imply auto:
>
> const foo(){return 5;}
>
> assert(foo() == 5);

It does not really "imply auto". 'auto' means nothing in this context, it's just a crutch for  the parser. The return type is deduced if it is left out. In order to leave it out, you need to provide some storage class. 'auto' is just one possibility.