Jump to page: 1 2
Thread overview
Preview features status?
May 19
evilrat
May 19
evilrat
Jul 13
Tejas
Jul 13
evilrat
Jul 14
Tejas
Jul 14
Tejas
Jul 14
Tejas
Jul 14
Tejas
May 19

There were recently new additions to -preview flag, will they stay? Is preview features generally means it is not going to be removed later?

Specifically what about these two?

-preview=rvaluerefparam
This one helps with C++ interop where it's the norm but is PITA in D.

-preview=shortenedMethods
And this one just gives nice and fresh look to the language

May 19

On Wednesday, 19 May 2021 at 07:36:53 UTC, evilrat wrote:

>

-preview=rvaluerefparam
This one helps with C++ interop where it's the norm but is PITA in D.

Well, ok D still got me sometimes even with that preview feature, this s**t isn't even fun...

// PxVec3 operator-
public PxVec3 opBinary(string op : "-")(ref const(PxVec3) v) const {
    return PxVec3(x - v.x, y - v.y, z - v.z);
}
	
public float distance(ref const(PxVec3) p) const {
    return p.dot(n) + d; // dot is also const
}

// original code, n is plain PxVec3, not const
public PxVec3 project(ref const(PxVec3) p) const {
    return p - n * distance(p); // error
}
>

Error: incompatible types for (p) - (this.n.opBinary(this.distance(p))): const(PxVec3) and PxVec3

// lets try this
public PxVec3 project(ref const(PxVec3) p) const {
    PxVec3 t = p;
    return t - n * distance(t); // error
}
>

Error: incompatible types for (t) - (this.n.opBinary(this.distance(t))): both operands are of type PxVec3

// ok, no error
public PxVec3 project(ref const(PxVec3) p) const {
    auto t = n * distance(p);
    pragma(msg, typeof(t)); // PxVec3
    return p - t; //
}

U MAD BRO?
July 13

On Wednesday, 19 May 2021 at 08:45:22 UTC, evilrat wrote:

>

On Wednesday, 19 May 2021 at 07:36:53 UTC, evilrat wrote:

>

-preview=rvaluerefparam
This one helps with C++ interop where it's the norm but is PITA in D.

Well, ok D still got me sometimes even with that preview feature, this s**t isn't even fun...

// PxVec3 operator-
public PxVec3 opBinary(string op : "-")(ref const(PxVec3) v) const {
    return PxVec3(x - v.x, y - v.y, z - v.z);
}
	
public float distance(ref const(PxVec3) p) const {
    return p.dot(n) + d; // dot is also const
}

// original code, n is plain PxVec3, not const
public PxVec3 project(ref const(PxVec3) p) const {
    return p - n * distance(p); // error
}
>

Error: incompatible types for (p) - (this.n.opBinary(this.distance(p))): const(PxVec3) and PxVec3

// lets try this
public PxVec3 project(ref const(PxVec3) p) const {
    PxVec3 t = p;
    return t - n * distance(t); // error
}
>

Error: incompatible types for (t) - (this.n.opBinary(this.distance(t))): both operands are of type PxVec3

// ok, no error
public PxVec3 project(ref const(PxVec3) p) const {
    auto t = n * distance(p);
    pragma(msg, typeof(t)); // PxVec3
    return p - t; //
}

U MAD BRO?

Shouldn't this be a bug? Isn't this still const - non-const?
Do you think this is worth filing?

Also, where did you find out how to represent rvalue references as parameters? I couldn't find any info on that. Just learned that these are available under a preview switch.

July 13

On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:

>

Shouldn't this be a bug? Isn't this still const - non-const?
Do you think this is worth filing?

Definitely a bug from usability point. But...

Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well.

https://github.com/dlang/dmd/pull/12064

>

Also, where did you find out how to represent rvalue references as parameters? I couldn't find any info on that. Just learned that these are available under a preview switch.

Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.

July 14

On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat wrote:

>

On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:

>

Shouldn't this be a bug? Isn't this still const - non-const?
Do you think this is worth filing?

Definitely a bug from usability point. But...

Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well.

https://github.com/dlang/dmd/pull/12064

>

Also, where did you find out how to represent rvalue references as parameters? I couldn't find any info on that. Just learned that these are available under a preview switch.

Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.

Here's the full picture from my POV:

-preview=rvaluerefparams was implemented by Walter and later documented. However when I tried to use it, I ran into the three issues that were linked in the PR you mentioned. I originally started working on fixing those, but realized that there were many unanswered questions. One of them was, what to do with mutable parameters ? This was one of the main rationale provided when the DIP was rejected.

This brought me back to an old idea of mine, which was to have in means const scope [ref] (ref when it makes sense), but the fact that it would conflict with passing rvalues to a function was always off-putting. Adding rvalue ref matching just made sense, so I went ahead and implemented it. I also made sure druntime/Phobos, Vibe.d, and many other packages on Buildkite were compatible.

I've been using it in production as soon as I could, which was v2.094.0 because -preview flags and DUB didn't play along well before. It's been a breeze, and doing everything exactly as we want it done, so I'm very happy with the result.

However, there has been some serious backlash from a few people. So I don't think it's going to be made the default any time soon (or at least, start the process), because it seems Walter is among those who doesn't like it. So unless we manage to convince the BDFLs that it's useful, it's not going out of -preview. However, I'll make sure it works in every release, as I use it everywhere.

July 14

On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat wrote:

>

On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:

>

Shouldn't this be a bug? Isn't this still const - non-const?
Do you think this is worth filing?

Definitely a bug from usability point. But...

Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well.

https://github.com/dlang/dmd/pull/12064

>

Also, where did you find out how to represent rvalue references as parameters? I couldn't find any info on that. Just learned that these are available under a preview switch.

Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.

Does your code "just work" if you use preview=in instead? Could be a good reason to just get rid of the rvaluerefparam then.

July 14

On Wednesday, 14 July 2021 at 02:54:26 UTC, Mathias LANG wrote:

>

On Tuesday, 13 July 2021 at 18:20:36 UTC, evilrat wrote:

>

On Tuesday, 13 July 2021 at 15:51:26 UTC, Tejas wrote:

>

Shouldn't this be a bug? Isn't this still const - non-const?
Do you think this is worth filing?

Definitely a bug from usability point. But...

Well, seems like it is just yet another half baked feature according to this GH issue, also it seems like it was supposed to be superseded by relevant "in" qualifier for extern(C++) but that DIP seems to be abandoned as well.

https://github.com/dlang/dmd/pull/12064

>

Also, where did you find out how to represent rvalue references as parameters? I couldn't find any info on that. Just learned that these are available under a preview switch.

Can't find it anywhere in release notes, it was just silently showed up around Apr 2019.

Here's the full picture from my POV:

-preview=rvaluerefparams was implemented by Walter and later documented. However when I tried to use it, I ran into the three issues that were linked in the PR you mentioned. I originally started working on fixing those, but realized that there were many unanswered questions. One of them was, what to do with mutable parameters ? This was one of the main rationale provided when the DIP was rejected.

This brought me back to an old idea of mine, which was to have in means const scope [ref] (ref when it makes sense), but the fact that it would conflict with passing rvalues to a function was always off-putting. Adding rvalue ref matching just made sense, so I went ahead and implemented it. I also made sure druntime/Phobos, Vibe.d, and many other packages on Buildkite were compatible.

I've been using it in production as soon as I could, which was v2.094.0 because -preview flags and DUB didn't play along well before. It's been a breeze, and doing everything exactly as we want it done, so I'm very happy with the result.

However, there has been some serious backlash from a few people. So I don't think it's going to be made the default any time soon (or at least, start the process), because it seems Walter is among those who doesn't like it. So unless we manage to convince the BDFLs that it's useful, it's not going out of -preview. However, I'll make sure it works in every release, as I use it everywhere.

I believe you're talking about this?
https://forum.dlang.org/thread/rl7c8t$sml$1@digitalmars.com

Well, I admit that their concerns aren't unfounded, but since yours is the only proposal still being maintained and worked on, we can try and think of ways regarding how to $(I deterministically) specify whether to receive an rvalue ref, or rvalue, or lvalue ref, or lvalue.

in could use deeper formalism, or we could try to develop a pass that checks for the aliases in the particular case shown.

Either way, since in is the only game in town, I guess. I'll also use it.

Thanks for your work in developing and maintaining it. Nothing's perfect the first time around :)

July 14

On Wednesday, 14 July 2021 at 07:26:27 UTC, Tejas wrote:

>

Does your code "just work" if you use preview=in instead? Could be a good reason to just get rid of the rvaluerefparam then.

Mostly. The main source of errors is that it will complain about in and ref being mixed together. The second is that, since it behaves as scope, if you escape parameter they might start to get diagnosed correctly.
Those are the two main reasons of failure I encountered while using it / adapting projects. I've never seen a place where parameter aliasing was causing issues.

Note that there are a few more things still missing for it to be complete: First, it needs to work with foreach (currently, foreach doesn't even support scope, so I'll do that too when I get to it), and the other is that it should probably error out with non-extern(D|C++) (https://github.com/dlang/dmd/pull/12242).

July 14

On Wednesday, 14 July 2021 at 08:00:12 UTC, Mathias LANG wrote:

>

Note that there are a few more things still missing for it to be complete: First, it needs to work with foreach (currently, foreach doesn't even support scope, so I'll do that too when I get to it), and the other is that it should probably error out with non-extern(D|C++) (https://github.com/dlang/dmd/pull/12242).

And storage class inference for function literals (https://issues.dlang.org/show_bug.cgi?id=9423), which will make everyone's life easier (and should allow other nice things, like allowing more ref in range pipelines).

July 14

On Wednesday, 14 July 2021 at 08:00:12 UTC, Mathias LANG wrote:

>

On Wednesday, 14 July 2021 at 07:26:27 UTC, Tejas wrote:

>

Does your code "just work" if you use preview=in instead? Could be a good reason to just get rid of the rvaluerefparam then.

Mostly. The main source of errors is that it will complain about in and ref being mixed together. The second is that, since it behaves as scope, if you escape parameter they might start to get diagnosed correctly.
Those are the two main reasons of failure I encountered while using it / adapting projects. I've never seen a place where parameter aliasing was causing issues.

Note that there are a few more things still missing for it to be complete: First, it needs to work with foreach (currently, foreach doesn't even support scope, so I'll do that too when I get to it), and the other is that it should probably error out with non-extern(D|C++) (https://github.com/dlang/dmd/pull/12242).

Last question:

How do you exactly specify that you're expecting a rvalue reference as a parameter?
In other words, what is the D equivalent of this C++ code:

func(T&& parameter) { }

« First   ‹ Prev
1 2