Add std.typecons.HeadConst (Continuation of #2881) #3862

JakobOvrum · 2015-12-08T04:15:02Z

Ressurection of #2881. Fixes the issue @monarchdodra pointed out by using std.typecons.Proxy.

Github didn't give me the option to reopen the old PR after I force pushed the new changes.

tsbockman · 2015-12-08T04:57:27Z

std/typecons.d

+    if (!is(T == const) && !is(T == immutable))
+{
+    private T HeadConst_value;
+    mixin Proxy!HeadConst_value;


When I comment this line out and add ref to the return type of HeadConst_get(), all of your unittests still pass.

How about adding another test or two documenting why Proxy is necessary?

Thanks, I added the relevant test. Further attempts to break it are much appreciated!

A naive viewpoint is that the alias this that returns an rvalue should be enough to implement head constness. Could you please document (privately and if needed to the user as well) why the proxy is necessary?

tsbockman · 2015-12-08T05:15:58Z

Further attempts to break it are much appreciated!

Since you asked...

void main(string[] args) {
    struct Fail {
        this(bool fail) { }
    }

    HeadConst!Fail fail = true; // Error: cannot access frame pointer of main.Fail
}

JakobOvrum · 2015-12-08T05:18:56Z

Hm, I don't know how to make it work with non-static nested structs or classes. You should be able to do: auto fail = headConst(Fail(true));. There might be a possible fix using alias parameters.

tsbockman · 2015-12-08T05:20:29Z

You should be able to do: auto fail = headConst(Fail(true));.

Yes, that works.

Hm, I don't know how to make it work with non-static nested structs or classes.

Can you at least detect such cases and print a better error message?

JakobOvrum · 2015-12-08T05:57:17Z

Can you at least detect such cases and print a better error message?

Done.

tsbockman · 2015-12-08T06:09:26Z

std/typecons.d

+        if (__traits(compiles, T(args)))
+    {
+        static assert((!is(T == struct) && !is(T == union)) || !isNested!T,
+            "Nested type " ~ fullyQualifiedName!T ~ " must be constructed " ~


"Nested type T must be marked as static or constructed explicitly at the call-site", etc.

Since the error triggers even when the context is not actually being used for anything, just marking the type as static is going to be the best fix most of the time (at least with the way I tend to use nested types).

The term "nested type" is usually reserved for non-static nested types. If the user didn't make it static then it should be assumed that this is intentional. Error messages are not tutorials.

tsbockman · 2015-12-08T06:30:44Z

@JakobOvrum

The term "nested type" is usually reserved for non-static nested types.

If so, then this is specific to D - C#, for instance has Nested Types which cannot capture their context at all.

If the user didn't make it static then it should be assumed that this is intentional.

If static were the default, I would agree. Since it's not though, it is entirely possible that the user simply assumed (correctly, I hope?) that the optimizer would remove the context pointer if it was not needed.

JakobOvrum · 2015-12-08T07:02:22Z

If so, then this is specific to D - C#, for instance has Nested Types which cannot capture their context at all.

We should not consider C# semantics in our error messages.

If static were the default, I would agree. Since it's not though, it is entirely possible that the user simply assumed (correctly, I hope?) that the optimizer would remove the context pointer if it was not needed.

Performance and optimization is a complete red herring.

Telling the user to mark the type as static is not an option because such an action breaks code that uses the context. The current message is correct in all cases.

tsbockman · 2015-12-08T07:29:02Z

We should not consider C# semantics in our error messages.

C# is just one example of many. I looked, and even the D language specification uses "nested" in a way that encompasses static types.

Performance and optimization is a complete red herring.

The point I was making, is that a user has no real incentive to mark a nested type as static unless it is required to make the code compile. This fact invalidates your claim: "If the user didn't make it static then it should be assumed that this is intentional."

Telling the user to mark the type as static is not an option because such an action breaks code that uses the context. The current message is correct in all cases.

My proposed message simply presents the user with an additional option. This will cause no problems for the user, unless he doesn't know what static does. Since "Error messages are not tutorials", this should not be a concern.

But, if you still want to argue I will let someone else answer, as I do not consider this detail to be a blocker.

At the moment, I see no other problems with this PR - except that, considering how hard it is to plug all the loopholes in a scheme like this, it might be best to run it through std.experimental first.

JakobOvrum · 2015-12-08T07:32:34Z

I've disambiguated the error message a little.

This fact invalidates your claim: "If the user didn't make it static then it should be assumed that this is intentional."

It is the conservative estimate. Users that don't know the difference can safely follow the advice.

tsbockman · 2015-12-08T07:35:10Z

I've disambiguated the error message a little.

Looks good. Thoughts on std.experimental?

JakobOvrum · 2015-12-08T07:39:47Z

Looks good. Thoughts on std.experimental?

Last time we discussed using std.experimental as a staging area for additions to existing modules it was met with a lot of resistance.

edit:

A relevant consideration is that the interface of HeadConst should not be expected to change beyond fixing bugs.

tsbockman · 2015-12-08T07:50:21Z

Last time we discussed using std.experimental as a staging area for additions to existing modules it was met with a lot of resistance.

Hmm. Seems like the biggest concern was uncertainty that anything would ever actually get migrated out of std.experimental once it went in.

I think HeadConst is a better candidate for the process in various ways than padLeft and padRight, but I guess it's better for it to go straight into std than get stuck in experimental indefinitely.

schveiguy · 2015-12-08T18:30:44Z

Last time we discussed using std.experimental as a staging area for additions to existing modules it was met with a lot of resistance.

I will note that most of the resistance was for requiring all changes to go through std.experimental. I think it's fine to put new pieces of a module into std.experimental (make sure you public import std.typecons from std.experimental.typecons).

Fix ticket 13796

dlang-bot · 2016-01-07T21:31:26Z

Fix	Bugzilla	Description
✓	13796	A simple "array head const" struct for Phobos

ntrel · 2016-02-17T11:37:17Z

std/typecons.d

+    assert(sboth.i == 42);
+
+    sboth.i = 24;
+    assert(sboth.i == 24);


For a C++ const struct field, shouldn't i stay constant?

I don't think preventing assignment for structs when fields can still be assigned to makes much sense.

DmitryOlshansky · 2016-03-09T15:01:30Z

Looks sensible. How about we name it Final as in Java's final (i.e. write once)?

PetarKirov · 2016-03-09T16:42:46Z

@DmitryOlshansky See the comments in the previous PR.
Also I think that Final is nice name for a type constructor like Proxy which would enable inlining by devirtualizing the methods of a class.

JakobOvrum · 2016-03-09T19:07:25Z

I originally called it Final. See #2881.

DmitryOlshansky · 2016-03-09T19:21:53Z

@JakobOvrum I'd still suggest Final if only for the reason that while HeadConst is pedantically correct it's an awful lot to type for a common need and for Final to be useful if it must not be a chore to use.

tsbockman · 2016-03-09T20:41:01Z

Another vote for Final - as @DmitryOlshansky said, HeadConst is just a little bit too much typing to feel natural for something like this.

PetarKirov · 2016-03-10T11:20:51Z

But, calling it Final would be inconsistent with the rest of the language! The only meaning that final has is in the context of inheritance, which is good. Just imagine exlaining to someone new to D that Final means head const and has nothing to do with final. Please keep such Java-isms out of D!

In the longer to term what I would like to see is:

HeadConst
TailConst - an alias to Rebindable

and either:

Nullable
NotNull - disallows the null value for reference types
or:
Optional - an alias to Nullable
Required - same as NotNull

Symmetry in API design is important. Please don't break it, just to appeal to Java users.

PetarKirov · 2016-03-10T11:27:04Z

Also anyone who doesn't like the correct name or doesn't feel like typing such a long name can just put alias in his code to Final, HC or even to some random non-ASCII unicode character.

DmitryOlshansky · 2016-03-10T12:00:04Z

@ZombineDev I don't see this problem - just say that Final is for write once variables.
Head const is not immediately obvious to outsiders and implies extra reasoning to understand that const is transitive, and that there is a special form of tail-const and only then see where the idea of head-const comes in.

PetarKirov · 2016-03-10T14:23:21Z

@DmitryOlshansky I don't think that an outsider would want to use HeadConst( or Final) if he doesn't understand that D's const is transitive. Only if D's transitive constness is unsuitable, one would want to reach for something as fine-grained as HeadConst or TailConst. BTW, we also have HeadUnshared which is used here.

Another reason why Final is bad name:
Let's take the following code for example class Person { string address; }. In which of the two examples below is more clear if it is ok to modify the address field?
A)

Final!Person person;
person.address = newAddress; // Is the allowed?! I thought that Person was write once?

B)

HeadConst!Person person;
person.address = newAddress;

JackStouffer · 2016-03-10T14:48:49Z

I have to agree with @ZombineDev

DmitryOlshansky · 2016-03-11T19:15:26Z

Another reason why Final is bad name:
Let's take the following code for example class Person { string address; }. In which of the two examples below is more clear if it is ok to modify the address field?

Yes, write one variables are like that - you can't rebin the name but you can overwrite all fields if that is allowed by its structure (i.e. they are all publicly accessible)

DmitryOlshansky · 2016-03-11T19:16:38Z

Personally I don't care for a name just that I for one would not type HeadConst anywhere suitable the semantical gains vs visual noise ratio is too low. So if everyone is for HeadConst so be it.

tsbockman · 2016-03-11T19:22:36Z

So if everyone is for HeadConst so be it.

Same here. Final is my preference, but I don't want to block this.

ntrel · 2016-03-20T16:48:12Z

Technically this should be called Unassignable IMO. HeadConst!Struct makes me think the struct's (public) fields should be head const, like in C++, and maybe we'll want a std.typecons wrapper for that in future. But in practice Final is a good short name.

PetarKirov · 2016-03-21T08:04:22Z

@ntrel HeadConst!Struct should be disallowed. HeadConst!T, just like TailConst!T (a.k.a. Rebindable!T) are only applicable when T is a reference type.

TailConst!(T*) -> const(T)*
TailConst!(const T*) -> const(T)*
HeadConst!(T*) -> T const(*)
HeadConst!(const T*) -> T const(*)

Obviously we need HeadConst because const(*) (or the equivalent for arrays and classes) can't be expressed in D.

The only meaning that final has is virtual(false). Let's keep it that way.

ntrel · 2016-03-21T15:25:45Z

@ZombineDev:

HeadConst!T [is] only applicable when T is a reference type

This pull allows HeadConst!Struct, which is why Unassignable is a more accurate name (it disables opAssign). Unassignable!Struct can be (somewhat) useful by preventing private fields of a struct from being changed through assignment.

andralex · 2016-06-05T00:51:21Z

std/typecons.d

+ +
+ + Head-const variables cannot be directly mutated or rebound, but references
+ + reached through the variable are typed with their original mutability.
+ + It is equivalent to $(D final) variables in D1 and Java, as well as


I think therefore Final would be a better choice than HeadConst

@andralex

I think therefore Final would be a better choice than HeadConst

Someone needs to make an executive decision about the name. It has already been debated (and changed once), with about a 50% / 50% split of votes:

For HeadConst: ZombineDev, JackStouffer, schuetzm, Dicebot

For Final: JakobOvrum, DmitryOlshansky, tsbockman (me), andralex

(Click the links if you want to skim the earlier discussion.)

andralex · 2016-06-05T17:01:41Z

OK. A good step forward is to put this in std.experimental, there's subtleties about it. Then we can defer zeroing in on a name.

andralex · 2016-06-07T17:06:27Z

For more detail: we should define std.experimental.typecons and put this in it. With that I preapprove this addition. Thanks!

JackStouffer · 2016-06-07T17:29:04Z

std.experimental.typecons

Already exists :)

wilzbach · 2016-08-15T10:41:22Z

For more detail: we should define std.experimental.typecons and put this in it. With that I preapprove this addition. Thanks!

This has been preapproved for more than two months - is someone interested in adopting the PR?
Maybe we can have an "orphan" tag?

wilzbach · 2016-08-29T01:43:20Z

This has been preapproved for more than two months - is someone interested in adopting the PR?
Maybe we can have an "orphan" tag?

I went ahead -> #4755 ;-)

wilzbach · 2016-08-29T16:56:08Z

I went ahead -> #4755 ;-)

Wow that was a super-fast resurrection! It's alive with #4755.

JakobOvrum force-pushed the final branch from d22a30c to ce53dfc Compare December 8, 2015 04:25

tsbockman reviewed Dec 8, 2015
View reviewed changes

JakobOvrum force-pushed the final branch from ce53dfc to 06cecc1 Compare December 8, 2015 05:02

JakobOvrum force-pushed the final branch 2 times, most recently from de5c444 to 0ec76f9 Compare December 8, 2015 05:56

tsbockman reviewed Dec 8, 2015
View reviewed changes

JakobOvrum force-pushed the final branch from 0ec76f9 to ad11eb1 Compare December 8, 2015 07:29

Add std.typecons.HeadConst

e6c66bb

Fix ticket 13796

JakobOvrum force-pushed the final branch from ad11eb1 to e6c66bb Compare January 7, 2016 21:31

ntrel reviewed Feb 17, 2016
View reviewed changes

DmitryOlshansky added the @andralex Approval from Andrei is required label May 5, 2016

andralex reviewed Jun 5, 2016
View reviewed changes

wilzbach mentioned this pull request Aug 29, 2016

Add std.experimental.typecons.Final #4755

Merged

wilzbach closed this Aug 29, 2016

JackStouffer mentioned this pull request Aug 29, 2016

Rename Final to Unassignable #4759

Closed

Add std.typecons.HeadConst (Continuation of #2881) #3862

Add std.typecons.HeadConst (Continuation of #2881) #3862

Conversation

JakobOvrum commented Dec 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tsbockman commented Dec 8, 2015

JakobOvrum commented Dec 8, 2015

tsbockman commented Dec 8, 2015

JakobOvrum commented Dec 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tsbockman commented Dec 8, 2015

JakobOvrum commented Dec 8, 2015

tsbockman commented Dec 8, 2015

JakobOvrum commented Dec 8, 2015

tsbockman commented Dec 8, 2015

JakobOvrum commented Dec 8, 2015

tsbockman commented Dec 8, 2015

schveiguy commented Dec 8, 2015

dlang-bot commented Jan 7, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DmitryOlshansky commented Mar 9, 2016

PetarKirov commented Mar 9, 2016

JakobOvrum commented Mar 9, 2016

DmitryOlshansky commented Mar 9, 2016

tsbockman commented Mar 9, 2016

PetarKirov commented Mar 10, 2016

PetarKirov commented Mar 10, 2016

DmitryOlshansky commented Mar 10, 2016

PetarKirov commented Mar 10, 2016

JackStouffer commented Mar 10, 2016

DmitryOlshansky commented Mar 11, 2016

DmitryOlshansky commented Mar 11, 2016

tsbockman commented Mar 11, 2016

ntrel commented Mar 20, 2016

PetarKirov commented Mar 21, 2016

ntrel commented Mar 21, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andralex commented Jun 5, 2016

andralex commented Jun 7, 2016

JackStouffer commented Jun 7, 2016

wilzbach commented Aug 15, 2016 • edited Loading

wilzbach commented Aug 29, 2016

wilzbach commented Aug 29, 2016

wilzbach commented Aug 15, 2016 •

edited

Loading