digitalmars.D.learn - dual-context deprecation
- jmh530 (36/36) May 17 2021 The code below (simplified from my actual problem) generates a
- Paul Backus (3/9) May 17 2021 See this issue for context:
- jmh530 (5/8) May 17 2021 Thanks. Lots of details there that I don't follow all of.
- Steven Schveighoffer (11/48) May 17 2021 The feature is deprecated in its current form. The issue as I understand...
- jmh530 (3/16) May 17 2021 That's a good summary. Thanks.
- 12345swordy (6/59) May 17 2021 The dual context that warning is referring to is vthis2, which
The code below (simplified from my actual problem) generates a warning that member function b "requires a dual-context, which is deprecated". However when I look at the list of deprecated features [1], I'm not seeing which one this is referring to. Is it a valid deprecation? I could only find this [2] reference to dual-contexts, which suggests that the problem relates to passing aliases into member functions. Moving it to a member function fixes the problem. Alternately, I could make the alias part of Foo's type. My use case it is just a little easier structured like this, but I get that there are workarounds. My bigger question is about why it isn't listed more than anything. I.e., should I file something in bugzilla. ```d struct Foo { double a; this(double x) { this.a = x; } double b(alias inverse)() { return inverse(a); } } void main() { auto foo = Foo(2.0); auto x = foo.b!(a => (10.0 ^^ a))(); } ``` [1] https://dlang.org/deprecate.html [2] https://forum.dlang.org/thread/mkeumwltwiimkrelgqrr forum.dlang.org
May 17 2021
On Monday, 17 May 2021 at 13:47:28 UTC, jmh530 wrote:The code below (simplified from my actual problem) generates a warning that member function b "requires a dual-context, which is deprecated". However when I look at the list of deprecated features [1], I'm not seeing which one this is referring to. Is it a valid deprecation?See this issue for context: https://issues.dlang.org/show_bug.cgi?id=5710
May 17 2021
On Monday, 17 May 2021 at 13:51:32 UTC, Paul Backus wrote:[snip] See this issue for context: https://issues.dlang.org/show_bug.cgi?id=5710Thanks. Lots of details there that I don't follow all of. I mentioned in the deprecation PR [1] that it was not listed in the list of deprecated features. [1] https://github.com/dlang/dmd/pull/9702
May 17 2021
On 5/17/21 9:47 AM, jmh530 wrote:The code below (simplified from my actual problem) generates a warning that member function b "requires a dual-context, which is deprecated". However when I look at the list of deprecated features [1], I'm not seeing which one this is referring to. Is it a valid deprecation? I could only find this [2] reference to dual-contexts, which suggests that the problem relates to passing aliases into member functions. Moving it to a member function fixes the problem. Alternately, I could make the alias part of Foo's type. My use case it is just a little easier structured like this, but I get that there are workarounds. My bigger question is about why it isn't listed more than anything. I.e., should I file something in bugzilla. ```d struct Foo { double a; this(double x) { this.a = x; } double b(alias inverse)() { return inverse(a); } } void main() { auto foo = Foo(2.0); auto x = foo.b!(a => (10.0 ^^ a))(); } ```The feature is deprecated in its current form. The issue as I understand it (i.e. very little) is that compilers other than DMD could not use this same way to implement dual contexts, and so they could not have the feature. This means that valid code in DMD would not compile on GDC or LDC. The way forward was to deprecate the mechanism used to implement it for DMD, and at some point tackle it in a backend-agnostic way. Personally, I don't know why we can't fix it so that it's portable, but I understand so little about compilers that I've pretty much stayed out of it. The feature is very much needed. -Steve
May 17 2021
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer wrote:[snip] The feature is deprecated in its current form. The issue as I understand it (i.e. very little) is that compilers other than DMD could not use this same way to implement dual contexts, and so they could not have the feature. This means that valid code in DMD would not compile on GDC or LDC. The way forward was to deprecate the mechanism used to implement it for DMD, and at some point tackle it in a backend-agnostic way. Personally, I don't know why we can't fix it so that it's portable, but I understand so little about compilers that I've pretty much stayed out of it. The feature is very much needed. -SteveThat's a good summary. Thanks.
May 17 2021
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer wrote:On 5/17/21 9:47 AM, jmh530 wrote:The dual context that warning is referring to is vthis2, which the gdc maintainer struggle to implemented for the gdc compiler. A correct fix involves templates having their own context. -AlexThe code below (simplified from my actual problem) generates a warning that member function b "requires a dual-context, which is deprecated". However when I look at the list of deprecated features [1], I'm not seeing which one this is referring to. Is it a valid deprecation? I could only find this [2] reference to dual-contexts, which suggests that the problem relates to passing aliases into member functions. Moving it to a member function fixes the problem. Alternately, I could make the alias part of Foo's type. My use case it is just a little easier structured like this, but I get that there are workarounds. My bigger question is about why it isn't listed more than anything. I.e., should I file something in bugzilla. ```d struct Foo { double a; this(double x) { this.a = x; } double b(alias inverse)() { return inverse(a); } } void main() { auto foo = Foo(2.0); auto x = foo.b!(a => (10.0 ^^ a))(); } ```The feature is deprecated in its current form. The issue as I understand it (i.e. very little) is that compilers other than DMD could not use this same way to implement dual contexts, and so they could not have the feature. This means that valid code in DMD would not compile on GDC or LDC. The way forward was to deprecate the mechanism used to implement it for DMD, and at some point tackle it in a backend-agnostic way. Personally, I don't know why we can't fix it so that it's portable, but I understand so little about compilers that I've pretty much stayed out of it. The feature is very much needed. -Steve
May 17 2021