Add lvalue/rvalue traits #1261

denis-sh · 2013-04-17T15:55:26Z

Add lvalue/rvalue traits
- rvalueOf/lvalueOf

(commits extracted from pull #954)

dnadlinger · 2013-04-22T17:27:33Z

std/traits.d

+
+
+/**
+Creates and lvalue or rvalue of type $(D T) for $(D typeof(...)) and


Typo: "creates and".

denis-sh · 2013-04-23T08:20:56Z

Is there a reason not to use documented unit test blocks here, or were they just not around when you first wrote that code?

The latter.

Fixed noted issues.

9rnsr · 2013-04-23T08:35:58Z

I think isLvalue template is not good. Contrary to the name, it does not work in all cases.

void main() {
    int x = 1;
    enum b = isLvalue!(1 + x);  // add expression makes rvalue but...
    // Error: variable x cannot be read at compile time  --> doesn't work!
}

We cannot fix the problem so it is an intrinsic limitation which comes from that isLvalue is implemented with template. I oppose to be adding such limited utility in standard library.

9rnsr · 2013-04-23T08:42:04Z

I can agree with adding lvalueOf and rvalueOf, but their implementations are not good currently.
@denis-sh , you can see the implementation of package template defaultInit in std.traits.

denis-sh · 2013-04-23T08:53:44Z

@9rnsr, I just changed lvalue/rvalue traits according to compiler change.
I will look at defaultInit now.

denis-sh · 2013-04-23T09:00:28Z

Rebased to fix merge conflicts.

Also I prefer my inout-hacking over defaultInit's one.

denis-sh · 2013-04-23T09:15:40Z

To @9rnsr:

We cannot fix the problem so it is an intrinsic limitation which comes from that isLvalue is implemented with template. I oppose to be adding such limited utility in standard library.

So, we can't use isLvalue(i) as variable i cannot be referenced at compile time. We have to either change it (the error) or use the proposed interface isLvalue!i which can be later improved with compiler changes to support your proposed usage.

Or we can make expectLvalue public thus having this dangerous interface:

static assert( __traits(compiles, expectLvalue(i)));
static assert(!__traits(compiles, expectLvalue(i + 1)));
static assert(!__traits(compiles, expectLvalue(f)));

9rnsr · 2013-04-23T09:32:42Z

The limitation is comes from that a template cannot take a runtime expression.

template X(T...) {}
void main() {
    int n;
    alias X1 = X!(n);   // take a symbol `n`.
    alias X2 = X!(int);   // take a type `int`.
    alias X3 = X!(1);   // take a value `1`.
  //alias X4 = X!(n + 1);   // cannot take an expression `n + 1`
}

This is current language design of D, not a bug. So we cannot implement isLvalue in library.

Or we can make expectLvalue public thus having this dangerous interface:

It is useless, because expectLvalue itself would provide nothing.

denis-sh · 2013-04-23T09:38:26Z

Other ugly but safe implementable interfaces:

Using mixin template:

mixin isLvalue!(`l_i`, q{i});
static assert(l_i);
mixin isLvalue!(`l_i1`, q{i + 1});
static assert(!l_i1);
static assert(!__traits(compiles, { mixin isLvalue!(`l_x`, q{x}); }));

Using string mixin:

static assert( mixin(isLvalue!q{i}));
static assert(!mixin(isLvalue!q{i + 1}));
static assert(!__traits(compiles, mixin(isLvalue!q{x})));

denis-sh · 2013-04-23T09:39:47Z

It is useless, because expectLvalue itself would provide nothing.

Don't understand. I shown usage in examples.

denis-sh · 2013-04-23T09:42:00Z

So we cannot implement isLvalue in library.

You mean "with this interface". What about other interfaces? Too ugly?

9rnsr · 2013-04-23T09:44:43Z

You mean "with this interface". What about other interfaces? Too ugly?

Yes, as you explained, we can provide it with the premise of using mixin. But it is too ugly. I cannot agree with it.

denis-sh · 2013-04-23T10:01:32Z

But it is too ugly. I cannot agree with it.

Me too. What about the first of proposed "other interfaces", isLvalue(i)? I filled an enhancement to make it work Issue 9980.

monarchdodra · 2013-08-02T09:42:35Z

What's the status here? I understand that there are problems with isLvalue? If that is the case, maybe it would be worth splitting the pull? rvalueOf/lvalueOf (I think) could be of great help when writting static ifs.

A lot of code uses T.init instead, which is only about 90% accurate in what it is actually testing...

denis-sh · 2013-08-02T10:10:04Z

What about to make isLvalue undocumented for now?

monarchdodra · 2013-08-11T15:59:32Z

What about to make isLvalue undocumented for now?

Package maybe, but not undocumented, that never ends well.

Are there many use cases for isLvalue ? I mean, does phobos even really need it? It definitly needs lvalueOf, that's for sure.

denis-sh · 2013-09-23T09:13:42Z

@9rnsr, I undocumented std.traits.isLvalue. Is anything else debatable in the pull? If not, lets merge.

monarchdodra · 2013-09-23T11:36:25Z

I undocumented std.traits.isLvalue.

Can't you make it package?

Is anything else debatable in the pull? If not, lets merge.

Yes: Given the discussions of @property and optional parenthesis, I don't think [EDIT:] ~~isLvalue~~ lvalueOf should be a @property (and, IMO, it is cleaner as a function). Making @property would prevent:

is(typeof(fun(&lvalueOf!T())));

Not supporting this syntax would just add one more pitfal in the pitfals that are initialization.

Ditto for rvalueOf: As a property, &rvalueOf!int would actually compile, whereas &rvalueOf!int() would result in a clean compile error (can't take address of rvalue)

9rnsr · 2013-09-23T12:00:27Z

I still think this isLvalue template is mis-designed and it should not be merged in Phobos.

denis-sh · 2013-09-23T12:08:44Z

I still think this isLvalue template is mis-designed and it should not be merged in Phobos.

Of course is is. So it is undocumented now and used only in unittests, where it is needed. Or must I mark it private? I don't like that as somebody may be OK to use undocumented stuff for now as we are not ready to provide better solution soon.

9rnsr · 2013-09-23T12:20:20Z

You can test lvalueOf and rvalueOf without using isLvalue, as follows.

unittest
{
    void accepstsLvalue(T)(ref T lval);
    ...
        static assert(!__traits(compiles, acceptsLvalue(rvalueOf!T)));
        static assert( __traits(compiles, acceptsLvalue(lvalueOf!T)));
}

I recommend to remove isLvalue definition completely.

denis-sh · 2013-09-23T12:21:01Z

To @monarchdodra:
I don't see the problem with these functions being @property as user isn't supposed to take the address of its return value. So for me you are complaining about a non-sense operation, sorry.
is(typeof(fun(&lvalueOf!T()))) is just and example of that chaos for me. As here one wants to pass rvalue of T* to fun and have to write __traits(compiles, fun(rvalueOf!(T*))) .

denis-sh · 2013-09-23T12:21:24Z

I recommend to remove isLvalue definition completely.

OK. Will do now.

denis-sh · 2013-09-23T12:44:55Z

@9rnsr, what about my f(inout T = default) workaround? Is it planned that property = value is rewritten to property(default) = value when value isn't convertible to T or just a compiler bug? There is no clear docs on the site and it's hard to find you related property fixing pulls and discussions.

denis-sh · 2013-09-23T12:45:56Z

As my previous inout trick worked because of a compiler bug it will be funny if the situation repeats. )

9rnsr · 2013-09-23T15:17:09Z

@denis-sh Hmm, how about this to disallow setter syntax?

template rvalueOf(T)
{
    @property T rvalueOf(inout int = 1);
    @property T rvalueOf(inout int) @disable;       // Disallow rvalueof!T = 1; syntax
}

/// ditto
template lvalueOf(T)
{
    @property ref T lvalueOf(inout int = 1);
    @property ref T lvalueOf(inout int) @disable;   // Disallow lvalueof!T = 1; syntax
}

The error message for the setter syntax misuse is not so friendly, but it works.

denis-sh · 2013-09-23T16:46:57Z

Hmm, how about this to disallow setter syntax?

As @monarchdodra noted, __traits(compiles, lvalueOf!Lhs = rvalueOf!Rhs) is what we need. My current solution works this way. As there is no cleaner variant and no relying on compiler bugs, let it stay so. Will add few more unittests now.

denis-sh · 2013-09-23T16:57:28Z

Added __traits(compiles, lvalueOf!byte = 127)-like tests.

monarchdodra · 2013-09-23T18:25:55Z

std/traits.d

@@ -4085,6 +4090,55 @@ unittest
 }


+struct __InoutWorkaroundStruct{}


private.

Also, could you document what you are working around? I have no idea what the whole inout __InoutWorkaroundStruct = __InoutWorkaroundStruct.init is about.

denis-sh · 2013-09-23T19:56:18Z

To @monarchdodra:

private

I was unsure private default argument will work. I just checked, currently it works. @9rnsr, is it a bug or planned behavior?

Also, could you document what you are working around?

OK.

monarchdodra · 2013-09-26T19:42:41Z

I was unsure private default argument will work.

I hadn't thought of that actually. I don't know then. It seems to work as private.

monarchdodra · 2013-09-26T19:49:33Z

std/traits.d

-        enum hasElaborateAssign = is(typeof(S.init.opAssign(S.init))) ||
-                                  is(typeof(S.init.opAssign(lvalueOf))) ||
+        enum hasElaborateAssign = is(typeof(S.init.opAssign(rvalueOf!S))) ||
+                                  is(typeof(S.init.opAssign(lvalueOf!S))) ||


Might as well also make these:

+ enum hasElaborateAssign = is(typeof(lvalueOf!S.opAssign(rvalueOf!S))) || + is(typeof(lvalueOf!S.opAssign(lvalueOf!S))) ||

No?

Might as well also make these
...
No?

Yes we can but I'd like to let it be this way as T.init.func looks already common. If it is bad, lets discuss and replace it everywhere.

monarchdodra · 2013-09-26T19:53:18Z

This pull looks merge-ready to me. Any body have anything else to add? @9rnsr ?

denis-sh · 2013-10-02T13:28:27Z

@9rnsr, ping. Are you OK with this?

9rnsr · 2013-10-02T15:11:08Z

The __InoutWorkaroundStruct hack is really ugly, but I agree there's no other better way.

LGTM.

Add lvalue/rvalue traits

CRLF EOLs were introduced in ea72723 commit of pull dlang#1261.

denis-sh mentioned this pull request Apr 17, 2013

Fix std.traits.hasElaborateAssign #954

Merged

dnadlinger reviewed Apr 22, 2013
View reviewed changes

std/traits.d

/**

Creates and lvalue or rvalue of type $(D T) for $(D typeof(...)) and

Copy link

Member

dnadlinger Apr 22, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: "creates and".

denis-sh mentioned this pull request Sep 23, 2013

Fix std.traits.isAssignable #1597

Merged

monarchdodra reviewed Sep 23, 2013
View reviewed changes

denis-sh added 2 commits September 23, 2013 23:54

Add rvalueOf/lvalueOf traits.

ea72723

Use std.traits.{rvalueOf,lvalueOf} in std.traits.hasElaborateAssign.

04768f0

monarchdodra reviewed Sep 26, 2013
View reviewed changes

9rnsr added a commit that referenced this pull request Oct 2, 2013

Merge pull request #1261 from denis-sh/add-lvalue-rvalue-traits

8b74811

Add lvalue/rvalue traits

9rnsr merged commit 8b74811 into dlang:master Oct 2, 2013

denis-sh mentioned this pull request Oct 2, 2013

Fix predicate template implementations in std.traits and std.range #842

Merged

denis-sh mentioned this pull request Oct 9, 2013

[Whitespace] Fix CRLF EOLs in std.traits. #1622

Merged

denis-sh added a commit to denis-sh/phobos that referenced this pull request Oct 9, 2013

[Whitespace] Fix CRLF EOLs in std.traits.

9a18458

CRLF EOLs were introduced in ea72723 commit of pull dlang#1261.



		/**
		Creates and lvalue or rvalue of type $(D T) for $(D typeof(...)) and

		@@ -4085,6 +4090,55 @@ unittest
		}


		struct __InoutWorkaroundStruct{}

Uh oh!

Add lvalue/rvalue traits #1261

Add lvalue/rvalue traits #1261

Uh oh!

Conversation

denis-sh commented Apr 17, 2013

Uh oh!

dnadlinger Apr 22, 2013

Choose a reason for hiding this comment

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

9rnsr commented Apr 23, 2013

Uh oh!

9rnsr commented Apr 23, 2013

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

9rnsr commented Apr 23, 2013

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

9rnsr commented Apr 23, 2013

Uh oh!

denis-sh commented Apr 23, 2013

Uh oh!

monarchdodra commented Aug 2, 2013

Uh oh!

denis-sh commented Aug 2, 2013

Uh oh!

monarchdodra commented Aug 11, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

monarchdodra commented Sep 23, 2013

Uh oh!

9rnsr commented Sep 23, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

9rnsr commented Sep 23, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

9rnsr commented Sep 23, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

monarchdodra Sep 23, 2013

Choose a reason for hiding this comment

Uh oh!

denis-sh commented Sep 23, 2013

Uh oh!

monarchdodra commented Sep 26, 2013

Uh oh!

monarchdodra Sep 26, 2013

Choose a reason for hiding this comment

Uh oh!

denis-sh Sep 26, 2013

Choose a reason for hiding this comment

Uh oh!

monarchdodra commented Sep 26, 2013

Uh oh!

denis-sh commented Oct 2, 2013