Add std.typecons.HeadConst

[JakobOvrum]

A simple type constructor that replicates the functionality of the now-defunct final variable storage class, allowing for easy creation of "read-only" variables and fields without going the full mile with transitive immutability. Using Final is quite a bit shorter than using a private variable with a public getter, and it's easier to get right since using a property correctly requires understanding of inout and the various function attributes. I guess it's also a nice thing to point to when queried about by Java programmers, and maybe even useful for porting Java code to D.

Please destroy.

[Panke]

this.data = T(args); ?

[JakobOvrum]

That would do exactly the same thing.

edit:

Added a test for construction with multiple arguments.

[Panke]

As far as I see, your code is the same as

this.data = this.data;

which is practically a no-op. Your unittest does not check if any field actually gets assigned. Of course it compiles, but it does not do anything meaningful.

[JakobOvrum]

Oops, I intended to do this.data = args;. Thanks!

[schuetzm]

How about calling it HeadConst? Final will only be understood by people coming from D1, and can also be confused with final classes.

[JakobOvrum]

D1 programmers, but also Java programmers. Final is also the name used to describe the same type in TDPL. HeadConst seems a little clumsy to me, but I'd love to hear what other people think the name should be.

[MetaLang]

If someone knows what a final class is, then they've probably used Java, and so they probably know what it means to mark a variable as final.

[mihails-strasuns]

I also find Final confusing. My first thought reading the PR name was "how it is related to final methods?"
Something like HeadConst or ReadOnly would be more obvious.

[PetarKirov]

+1 for naming it HeadConst. I find it far more descriptive than Final, which can cause confusion. (ReadOnly doesn't say anything about the transitivity.)

[JakobOvrum]

Renamed it to HeadConst.

[ghost]

LGTM!

@andralex can we get an approval for this?

[monarchdodra]

tabs2spaces please.

[monarchdodra]

No headConst helper-builder?

[monarchdodra]

Is this actually a public function we want users to be able to use? I realize it probably needs to be public for the bellow alias to work, but let's not document it that way.

[monarchdodra]

This is not pure nothrow (etc...), as it depends on the attributes applied to T's postblit.

Speaking of which, it might be worth having a const-by-ref overload.

[JakobOvrum]

Is this actually a public function we want users to be able to use? I realize it probably needs to be public for the bellow alias to work, but let's not document it that way.

Yeah, it's public for AliasThis to work. I chose to document it because it's currently not possible to document an AliasThis declaration with DDoc, but it could simply be mentioned in the type description instead.

This is not pure nothrow (etc...), as it depends on the attributes applied to T's postblit.

You're right, I was hoping the postblit operator would be called in the environment of the callsite :( Removing the explicit attributes and relying on inference seems to work well.

Speaking of which, it might be worth having a const-by-ref overload.

I tried this, but the const-by-ref overload is never chosen when the this-reference is const, and when I make it inout like the other overload, I get "matches both" errors.

[monarchdodra]

I like the idea, but I am less than thrilled about the following behavior:

import std.stdio;

struct S
{
    int i;
    void doit() {
            ++i;        
    }
}

void main()
{
    HeadConst!S s;
    s.i = 5; //No-op
    writeln(s.i);
    s.doit(); //No-op
    writeln(s.i);
}

I realize S is a value type, but still.

At the very least, I argue that for non-explicit reference types (classes, pointers, interfaces), than alias this should simply resolve to a const variable. Accessing a mutable copy should be done via an explicit "get()" or "copy()" or something.

Having alias this do anything more than return a ref to a field has always led to problems at one point or another...

[JakobOvrum]

I like the idea, but I am less than thrilled about the following behavior:

Ouch, didn't notice that one. Maybe some opDispatch magic can fix it, but there could be other problems... I'll try some things.

At the very least, I argue that for non-explicit reference types (classes, pointers, interfaces), than alias this should simply resolve to a const variable. Accessing a mutable copy should be done via an explicit "get()" or "copy()" or something.

I think this type is much less appealing if it's not a drop-in replacement for T.

Having alias this do anything more than return a ref to a field has always led to problems at one point or another...

Although it would make the implementation much more involved, we could always go the Proxy approach. But I'll see if I can make something work with AliasThis.

[JakobOvrum]

I'm going to close this for now and prioritise other things. If someone wants to spearhead this they are more than welcome to pick up where I left it. I think a correct implementation needs to use operator overloading (notably opDispatch) like Proxy does.