[Issue 24554] New: Clarrification for bad codegen on postfix operators

https://issues.dlang.org/show_bug.cgi?id=24554 Issue ID: 24554 Summary: Clarrification for bad codegen on postfix operators Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

[Issue 24510] Perfect forwarding and explicit move should be compiler intrinsic and have operators

agree that these should be intrinsics, mainly because the compiler can handle this much much more efficiently than the template bloat of the current library implementations. But I don't think we need new ugly operators for that, simply keeping the self-explanatory `move` and `forward` names. --

[Issue 24510] Perfect forwarding and explicit move should be compiler intrinsic and have operators

https://issues.dlang.org/show_bug.cgi?id=24510 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --

[Issue 24510] New: Perfect forwarding and explicit move should be compiler intrinsic and have operators

https://issues.dlang.org/show_bug.cgi?id=24510 Issue ID: 24510 Summary: Perfect forwarding and explicit move should be compiler intrinsic and have operators Product: D Version: D2 Hardware: All OS: All

[Issue 11500] Bringing mixed-in operators and constructors to the overload set

https://issues.dlang.org/show_bug.cgi?id=11500 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --

[Issue 11094] Disuniform error messages with overloaded + and ^ operators

https://issues.dlang.org/show_bug.cgi?id=11094 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --

[Issue 9786] Allow [non-member|UFCS] implementation of operators

https://issues.dlang.org/show_bug.cgi?id=9786 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --

[Issue 14364] Spec is incorrect for opAssign operators.

https://issues.dlang.org/show_bug.cgi?id=14364 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --

[Issue 12559] Multi operators with template mixins produces an error

https://issues.dlang.org/show_bug.cgi?id=12559 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --

[Issue 21124] Multiple templated is expressions used with logical operators

https://issues.dlang.org/show_bug.cgi?id=21124 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --

Re: Blog post on keeping D1 operators for D 2.100

On Saturday, 11 June 2022 at 21:57:36 UTC, Steven Schveighoffer wrote: https://www.schveiguy.com/blog/2022/06/how-to-keep-using-d1-operator-overloads/ -Steve `Good article `,and [chinese version](https://fqbqrr.blog.csdn.net/article/details/125265063)

Blog post on keeping D1 operators for D 2.100

D 2.100.0 removed support for D1 operator overloads. If you have a bunch of code that still uses them, and don't want to spend the time to upgrade to D2 overloads, you can still do it, using a mixin. Here's how it works (and shows off some cool metaprogramming features of D):

[Issue 11094] Disuniform error messages with overloaded + and ^ operators

https://issues.dlang.org/show_bug.cgi?id=11094 Ben changed: What|Removed |Added CC||ben.james.jo...@gmail.com --- Comment #2 from Ben

Re: Mixin Templates and Operators

On Wednesday, 6 April 2022 at 17:59:12 UTC, Adam D Ruppe wrote: ooh yeah there's multiple here so the names don't overload and one on the time itself would override the ones from mixin template. You'd have to alias them together on the type. Hello Adam D Ruppe, I see what you

Re: Mixin Templates and Operators

On Wednesday, 6 April 2022 at 17:33:28 UTC, Steven Schveighoffer wrote: As I mentioned elsewhere, it does work. But the situation I think must be that it's only one mixin template. Probably also you can't have any overloads in the type itself. Note that I also think string mixins would work

Re: Mixin Templates and Operators

On Wednesday, 6 April 2022 at 16:36:51 UTC, Tejas wrote: Looks like a compiler bug, since substituting the real methods makes the `mixin template` code compile fine Hi Tejas, Thank you very much for your answer! Also, remove the `const`, otherwise the method will word only on `const`

Re: Mixin Templates and Operators

On Wednesday, 6 April 2022 at 17:33:28 UTC, Steven Schveighoffer wrote: As I mentioned elsewhere, it does work. But the situation I think must be that it's only one mixin template. Probably also you can't have any overloads in the type itself. ooh yeah there's multiple here so the

Re: Mixin Templates and Operators

On 4/6/22 12:52 PM, Adam D Ruppe wrote: On Wednesday, 6 April 2022 at 10:36:04 UTC, francesco.andreetto wrote: Am I doing something wrong or it is impossible to use mixin templates like that? mixin templates can't bring in operator overloads. The spec doesn't really say this I think, but

Re: Mixin Templates and Operators

On 4/6/22 6:36 AM, francesco.andreetto wrote: I have two structs, point and vec, in which I want to implement some arithmetic operations. The operations are: ``` point - point = vec point + vec = point ``` Using mixin templates the code compiles but calling the operations in the main causes

Re: Mixin Templates and Operators

On Wednesday, 6 April 2022 at 10:36:04 UTC, francesco.andreetto wrote: Am I doing something wrong or it is impossible to use mixin templates like that? mixin templates can't bring in operator overloads. The spec doesn't really say this I think, but that's the way it has been for a long time.

Re: Mixin Templates and Operators

On Wednesday, 6 April 2022 at 10:36:04 UTC, francesco.andreetto wrote: I have two structs, point and vec, in which I want to implement some arithmetic operations. The operations are: ``` point - point = vec point + vec = point ``` Using mixin templates the code compiles but calling the

Mixin Templates and Operators

I have two structs, point and vec, in which I want to implement some arithmetic operations. The operations are: ``` point - point = vec point + vec = point ``` Using mixin templates the code compiles but calling the operations in the main causes an "incompatible type" Error: ```d mixin

Re: Which operators cannot be overloaded and why not?

On Mon, Sep 13, 2021 at 06:19:20PM +, NonNull via Digitalmars-d-learn wrote: > On Monday, 13 September 2021 at 16:12:34 UTC, H. S. Teoh wrote: > > On Mon, Sep 13, 2021 at 02:12:36PM +, NonNull via > > Digitalmars-d-learn wrote: > > > Which operators cann

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 16:12:34 UTC, H. S. Teoh wrote: On Mon, Sep 13, 2021 at 02:12:36PM +, NonNull via Digitalmars-d-learn wrote: Which operators cannot be overloaded and why not? Others have already given the list, so I won't repeat that. I didn't see unary &. Maybe ot

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 18:06:42 UTC, NonNull wrote: On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary && and || https://dlang.org/spec/operatoroverloading.html l

Re: Which operators cannot be overloaded and why not?

On Mon, Sep 13, 2021 at 02:12:36PM +, NonNull via Digitalmars-d-learn wrote: > Which operators cannot be overloaded and why not? Others have already given the list, so I won't repeat that. As to the "why": In general, D tries to avoid the wild wild west, every operator for hims

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:59:38 UTC, Paul Backus wrote: On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 15:29:05 UTC, user1234 wrote: [...] so this is a bit like the postincr case. i.e "prevent the semantics to be hijacked".

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary && and || They are all indirectly supported if `opCast` is ov

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary && and || https://dlang.org/spec/operatoroverloading.html l

Re: Which operators cannot be overloaded and why not?

On 9/13/21 10:47 AM, user1234 wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: what else ? when you have ```d alias AA1 = int[int]; alias AA2 = AA1[int]; ``` then you can write ```d AA2 aa; aa[0] = [0 : 0]; aa[0][0] = 0; ``` The `[0][0]` cannot be expressed using

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary && and || https://dlang.org/spec/operatoroverloading.html l

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: what else ? when you have ```d alias AA1 = int[int]; alias AA2 = AA1[int]; ``` then you can write ```d AA2 aa; aa[0] = [0 : 0]; aa[0][0] = 0; ``` The `[0][0]` cannot be expressed using operator overloads (and a custom map type

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary && and || https://dlang.org/spec/operatoroverloading.html lists all the overloadable operators, and https://dlang.

Re: Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:12:36 UTC, NonNull wrote: Which operators cannot be overloaded and why not? Let's start the list. - `new` and `delete` Because operators are overloaded in aggregates new was supported but not anymore, the idea is that a an aggregate should not be tied

Which operators cannot be overloaded and why not?

Which operators cannot be overloaded and why not?

Re: Not allowed to globally overload operators?

On Tuesday, 20 July 2021 at 18:32:26 UTC, Ali Çehreli wrote: On 7/19/21 11:20 PM, Tejas wrote: > trying to create the spaceship operator of C++ Just to make sure, D's opCmp returns an int. That new C++ operator was added to provide the same semantics. Ali I know. As I already mentioned,

Re: Not allowed to globally overload operators?

On 7/20/21 11:49 AM, H. S. Teoh wrote: > On Tue, Jul 20, 2021 at 11:32:26AM -0700, Ali Çehreli via Digitalmars-d-learn wrote: >> On 7/19/21 11:20 PM, Tejas wrote: >> >>> trying to create the spaceship operator of C++ >> >> Just to make sure, D's opCmp returns an int. That new C++ operator was

Re: Not allowed to globally overload operators?

On Tuesday, 20 July 2021 at 18:49:07 UTC, H. S. Teoh wrote: On Tue, Jul 20, 2021 at 11:32:26AM -0700, Ali Çehreli via Digitalmars-d-learn wrote: On 7/19/21 11:20 PM, Tejas wrote: > trying to create the spaceship operator of C++ Just to make sure, D's opCmp returns an int. That new C++

Re: Not allowed to globally overload operators?

On Tue, Jul 20, 2021 at 11:32:26AM -0700, Ali Çehreli via Digitalmars-d-learn wrote: > On 7/19/21 11:20 PM, Tejas wrote: > > > trying to create the spaceship operator of C++ > > Just to make sure, D's opCmp returns an int. That new C++ operator was > added to provide the same semantics. [...]

Re: Not allowed to globally overload operators?

On 7/19/21 11:20 PM, Tejas wrote: > trying to create the spaceship operator of C++ Just to make sure, D's opCmp returns an int. That new C++ operator was added to provide the same semantics. Ali

Re: Not allowed to globally overload operators?

On Tuesday, 20 July 2021 at 06:34:45 UTC, vit wrote: On Tuesday, 20 July 2021 at 06:20:34 UTC, Tejas wrote: ... Initially, I was trying to create the spaceship operator of C++, but we aren't allowed to create new operators ... D has spaceship operator: opCmp (https://dlang.org/spec

Re: Not allowed to globally overload operators?

On Tuesday, 20 July 2021 at 06:30:56 UTC, Mike Parker wrote: On Tuesday, 20 July 2021 at 06:20:34 UTC, Tejas wrote: Why isn't it working by default? Initially, I was trying to create the spaceship operator of C++, but we aren't allowed to create new operators, it seems. Then I just wanted

Re: Not allowed to globally overload operators?

On Tuesday, 20 July 2021 at 06:20:34 UTC, Tejas wrote: Why isn't it working by default? Initially, I was trying to create the spaceship operator of C++, but we aren't allowed to create new operators, it seems. Then I just wanted to verify whether we can even overload an operator globally

Re: Not allowed to globally overload operators?

On Tuesday, 20 July 2021 at 06:20:34 UTC, Tejas wrote: ... Initially, I was trying to create the spaceship operator of C++, but we aren't allowed to create new operators ... D has spaceship operator: opCmp (https://dlang.org/spec/operatoroverloading.html#compare).

Not allowed to globally overload operators?

ry!"+"(1,5); ``` It works as expected. Why isn't it working by default? Initially, I was trying to create the spaceship operator of C++, but we aren't allowed to create new operators, it seems. Then I just wanted to verify whether we can even overload an operator globally, but even that

[Issue 2450] Error using operators from named template mixin

https://issues.dlang.org/show_bug.cgi?id=2450 --- Comment #4 from Dlang Bot --- dlang/dmd pull request #12600 "merge stable" was merged into master: - 79a6f7cf9d604eea33b072a9ab30170daeeda696 by Boris Carvajal: Fix Issue 2450 - Error using operators from named template mixin

[Issue 2450] Error using operators from named template mixin

https://issues.dlang.org/show_bug.cgi?id=2450 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #12542 "Fix Issue 2450 - Error using operators from named template mixin (version 2)" was merged into stable: - b071e9d04e8db0612d6c3350a6383d7e1ae0eecc by Boris Carvajal: Fix

[Issue 21758] std.experimental.checkedint opBinaryRight with integer left-hand side does not compile for any operators except + and -

teger left-hand side does not compile for any operators except + and - https://github.com/dlang/phobos/pull/8012 --

[Issue 21758] std.experimental.checkedint opBinaryRight with integer left-hand side does not compile for any operators except + and -

teger left-hand side does not compile for any operators except + and - https://github.com/dlang/phobos/pull/7964 --

Re: How to allow +=, -=, etc operators and keep encapsulation?

On 4/12/21 2:16 PM, Jack wrote: Give this class: ```d class A { int X() { return x; } int X(int v) { return x = v;} private int x; } ``` I'd like to allow use ```+=```, ```-=``` operators on ```X()``` and keep encapsulation. What's a somehow elegant way to do that? It's

Re: How to allow +=, -=, etc operators and keep encapsulation?

On Monday, 12 April 2021 at 18:16:14 UTC, Jack wrote: Give this class: ```d class A { int X() { return x; } int X(int v) { return x = v;} private int x; } ``` I'd like to allow use ```+=```, ```-=``` operators on ```X()``` and keep encapsulation. What's a somehow

How to allow +=, -=, etc operators and keep encapsulation?

Give this class: ```d class A { int X() { return x; } int X(int v) { return x = v;} private int x; } ``` I'd like to allow use ```+=```, ```-=``` operators on ```X()``` and keep encapsulation. What's a somehow elegant way to do that?

[Issue 21758] std.experimental.checkedint opBinaryRight with integer left-hand side does not compile for any operators except + and -

|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7908 "std.experimental.checkedint opBinaryRight with integer left-hand side does not compile for any operators except + and -" was merged into stable: - 9dc134c8db1f9a547552e471d9b5a5009a6b64b7 by Nathan Sashih

[Issue 21758] std.experimental.checkedint opBinaryRight with integer left-hand side does not compile for any operators except + and -

created dlang/phobos pull request #7908 "std.experimental.checkedint opBinaryRight with integer left-hand side does not compile for any operators except + and -" fixing this issue: - Fix Issue 21758 - std.experimental.checkedint opBinaryRight with integer left-hand side does not compi

[Issue 21758] std.experimental.checkedint opBinaryRight with integer left-hand side does not compile for any operators except + and -

|opBinaryRight with integer |opBinaryRight with integer |left-hand side does not |left-hand side does not |compile for any operations |compile for any operators |except + and - |except + and - --

Re: Unary operators for Variants

On Tuesday, 9 March 2021 at 20:05:07 UTC, Jeff wrote: So, I can't seem to get unary operators to work with variants. For example: Variant x = 10; writeln(-x); // Error: x is not of arithmetic type, it is a VariantN!32LU Obviously binary operators like + work fine. Is there a reason opUnary

Unary operators for Variants

So, I can't seem to get unary operators to work with variants. For example: Variant x = 10; writeln(-x); // Error: x is not of arithmetic type, it is a VariantN!32LU Obviously binary operators like + work fine. Is there a reason opUnary wasn't implemented as well? Is there a work-around

[Issue 21124] New: Multiple templated is expressions used with logical operators

https://issues.dlang.org/show_bug.cgi?id=21124 Issue ID: 21124 Summary: Multiple templated is expressions used with logical operators Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW

Re: Overload comparison operators for "nullable" types

On Thursday, 30 July 2020 at 14:52:17 UTC, H. S. Teoh wrote: On Thu, Jul 30, 2020 at 01:41:05PM +, Oleg B via Digitalmars-d-learn wrote: [...] Logically we can compare versions, but what must return `opCmp` if one of versions has 'not comparible' state? [...] opCmp is allowed to return

Re: Overload comparison operators for "nullable" types

On Thu, Jul 30, 2020 at 01:41:05PM +, Oleg B via Digitalmars-d-learn wrote: [...] > Logically we can compare versions, but what must return `opCmp` if one of > versions has 'not comparible' state? [...] opCmp is allowed to return float; so you could return float.nan in this case. T --

Overload comparison operators for "nullable" types

strategy of throwing exception in `opCmp` is bad because some types can be 'not comparible' not because they is `null` or `undefined`, 'not comparible' can be two objects in some working states. If we add `opEquals` we can check 'not comparible' and return `false`, but operators `a <

Re: Is it possible to implement operators as ordinary functions?

On Tuesday, 19 May 2020 at 02:42:22 UTC, Adam D. Ruppe wrote: On Tuesday, 19 May 2020 at 02:36:24 UTC, data pulverizer wrote: I was wandering if it possible to implement operators as ordinary functions instead of as member functions of a class or struct for example something like this: nope

Re: Is it possible to implement operators as ordinary functions?

On Tuesday, 19 May 2020 at 02:36:24 UTC, data pulverizer wrote: I was wandering if it possible to implement operators as ordinary functions instead of as member functions of a class or struct for example something like this: nope, it must be done as member functions.

Is it possible to implement operators as ordinary functions?

I was wandering if it possible to implement operators as ordinary functions instead of as member functions of a class or struct for example something like this: ``` import std.stdio: writeln; struct Int{ int data = 0; } Int opBinary(string op)(Int x1, Int x2) { static if((op

Compiler bug ? -preview=intpromote and Integral promotion rules not being followed for unary + - ~ operators

I have a container which provides access to data via a handle. For book keeping I calculate some bitmasks. Previously, when the handle type as well as the constants were uint, everything compiled fine. Today I added a template parameter to be able to specify the handle type and I ran into this

[Issue 11964] Poor diagnostic in static assert with boolean operators

https://issues.dlang.org/show_bug.cgi?id=11964 Basile-z changed: What|Removed |Added CC|b2.t...@gmx.com | --

[Issue 11964] Poor diagnostic in static assert with boolean operators

https://issues.dlang.org/show_bug.cgi?id=11964 Basile-z changed: What|Removed |Added Keywords||diagnostic Status|NEW

[Issue 1974] overloaded assignment operators work on non-lvalues

https://issues.dlang.org/show_bug.cgi?id=1974 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Issue 20210] version blocks with boolean operators

https://issues.dlang.org/show_bug.cgi?id=20210 anonymous4 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Issue 2450] Error using operators from named template mixin

|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #10406 "Fix Issue 2450 - Error using operators from named template mixin" was merged into master: - dd79b0cb45ef8686978f6b5896cb829af8120ff7 by RazvanN7: Fix Issue 2450 - Error using operators from named temp

[Issue 2450] Error using operators from named template mixin

--- @RazvanN7 created dlang/dmd pull request #10406 "Fix Issue 2450 - Error using operators from named template mixin" fixing this issue: - Fix Issue 2450 - Error using operators from named template mixin https://github.com/dlang/dmd/pull/10406 --

[Issue 20210] version blocks with boolean operators

https://issues.dlang.org/show_bug.cgi?id=20210 --- Comment #1 from KnightMare --- this issue comes from https://issues.dlang.org/show_bug.cgi?id=20211 where I tried to determine probably existing version "OT:" comes from issue:20211 too. then I decided to split issues. so just ignore "OT:" in

[Issue 20210] New: version blocks with boolean operators

https://issues.dlang.org/show_bug.cgi?id=20210 Issue ID: 20210 Summary: version blocks with boolean operators Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement

[Issue 1974] overloaded assignment operators work on non-lvalues

https://issues.dlang.org/show_bug.cgi?id=1974 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from

Re: Do @property attributes not allow postincrement operators

On Sunday, 14 April 2019 at 02:11:52 UTC, Mike Franklin wrote: On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote: Do @property attributes not allow postincrement operators? ... It's a long standing issue (going on 7 years old) ... I plan on getting to it, but there are other pressing

Re: Do @property attributes not allow postincrement operators

On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote: Do @property attributes not allow postincrement operators? import std.stdio; struct Foo { @property bar() { return 10; } @property bar(int x) { writeln(x); } } void main() { Foo foo; writeln(foo.bar); // actually calls

Do @property attributes not allow postincrement operators

Do @property attributes not allow postincrement operators? import std.stdio; struct Foo { @property bar() { return 10; } @property bar(int x) { writeln(x); } } void main() { Foo foo; writeln(foo.bar); // actually calls foo.bar(); foo.bar = 10; // calls foo.bar(10

[Issue 11500] Bringing mixed-in operators and constructors to the overload set

https://issues.dlang.org/show_bug.cgi?id=11500 Basile-z changed: What|Removed |Added See Also||https://issues.dlang.org/sh |

[Issue 19200] Variant operators don't overload correctly

https://issues.dlang.org/show_bug.cgi?id=19200 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 19200] Variant operators don't overload correctly

/4873119553666819b4810a1318998eaad7476b08 Merge pull request #6684 from Biotronic/issue-19200 Fix issue 19200 - Variant operators don't overload correctly merged-on-behalf-of: Petar Kirov --

[Issue 19200] New: Variant operators don't overload correctly

https://issues.dlang.org/show_bug.cgi?id=19200 Issue ID: 19200 Summary: Variant operators don't overload correctly Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal

Re: Tired by deprecation message for unary operators on 8/16 bit vars ? A simple solution

On Thu, Jun 07, 2018 at 05:02:09PM +, Johan Engelen via Digitalmars-d wrote: > On Thursday, 7 June 2018 at 15:18:49 UTC, H. S. Teoh wrote: > > > > Now all you have to do is to add operator overloading to make the > > wrapper type infectious, and a convenience function that can be > > easily

Re: Tired by deprecation message for unary operators on 8/16 bit vars ? A simple solution

On Thursday, 7 June 2018 at 15:18:49 UTC, H. S. Teoh wrote: Now all you have to do is to add operator overloading to make the wrapper type infectious, and a convenience function that can be easily typed, and you get: [...] I'd like to have this in the stdlib, what are the chances? -Johan

Re: Tired by deprecation message for unary operators on 8/16 bit vars ? A simple solution

On Thu, Jun 07, 2018 at 03:52:10PM +, Basile B. via Digitalmars-d wrote: > On Thursday, 7 June 2018 at 15:18:49 UTC, H. S. Teoh wrote: > > On Thu, Jun 07, 2018 at 01:42:17PM +, Basile B. via Digitalmars-d > > wrote: > > > [...] > > [...] > > > > You're on the right track. Now all you have

Re: Tired by deprecation message for unary operators on 8/16 bit vars ? A simple solution

On Thursday, 7 June 2018 at 15:18:49 UTC, H. S. Teoh wrote: On Thu, Jun 07, 2018 at 01:42:17PM +, Basile B. via Digitalmars-d wrote: [...] [...] You're on the right track. Now all you have to do is to add operator overloading to make the wrapper type infectious, and a convenience

Re: Tired by deprecation message for unary operators on 8/16 bit vars ? A simple solution

containing Np should automatically use Np * operator semantics. */ Np opBinaryRight(string op, U)(U u) if (is(typeof((T x, U y) => mixin("x " ~ op ~ " y" { return Np(cast(T) mixin("u " ~ op ~ " this.impl")); }

Tired by deprecation message for unary operators on 8/16 bit vars ? A simple solution

I don't know if this is a bug but this works: ``` module runnable; struct Byte { byte value; alias value this;} void main() { {Byte b; auto c = ~b;} // no message {byte b; auto c = ~b;} // deprecation... } ``` --- Baz

Re: lazy evaluation of logical operators in enum definition

On Wednesday, 18 April 2018 at 10:19:20 UTC, Atila Neves wrote: On Wednesday, 18 April 2018 at 04:44:23 UTC, Shachar Shemesh wrote: On 17/04/18 13:59, Simen Kjærås wrote: [...] Also, extremely dangerous. Seriously, guys and gals. __traits(compiles) (and its uglier sibling, is(typeof()))

Re: lazy evaluation of logical operators in enum definition

On 18.04.2018 09:18, Walter Bright wrote: On 4/15/2018 10:57 PM, Shachar Shemesh wrote: It seems that the && evaluation does not stop when the first false is found. Evaluation does stop, semantic analysis does not. For example:   bool foo() {     return 0 && undefined_variable;   } does

Re: lazy evaluation of logical operators in enum definition

On Wednesday, 18 April 2018 at 04:44:23 UTC, Shachar Shemesh wrote: On 17/04/18 13:59, Simen Kjærås wrote: [...] Also, extremely dangerous. Seriously, guys and gals. __traits(compiles) (and its uglier sibling, is(typeof())) should be used *extremely* sparingly. [...] A very good rule of

Re: lazy evaluation of logical operators in enum definition

On 4/15/2018 10:57 PM, Shachar Shemesh wrote: It seems that the && evaluation does not stop when the first false is found. Evaluation does stop, semantic analysis does not. For example: bool foo() { return 0 && undefined_variable; } does not compile. I'd speculate that most would

Re: lazy evaluation of logical operators in enum definition

On 17/04/18 13:59, Simen Kjærås wrote: There's a kinda neat (and kinda ugly) way to implement prop in one line:     enum prop(T) = __traits(compiles, { static assert(T.member == 3); }); Now, that's not the same as short-circuiting, and only useful in some cases, but for those cases, it's

Re: lazy evaluation of logical operators in enum definition

On Monday, 16 April 2018 at 05:57:01 UTC, Shachar Shemesh wrote: Consider the following program: struct S1 { enum member = 3; } struct S2 { enum member = 2; } struct S3 { } enum prop(T) = __traits(hasMember, T, "member") && T.member==3; pragma(msg, prop!S1); pragma(msg, prop!S2);

Re: lazy evaluation of logical operators in enum definition

On Monday, 16 April 2018 at 05:57:01 UTC, Shachar Shemesh wrote: Consider the following program: struct S1 { enum member = 3; } struct S2 { enum member = 2; } struct S3 { } enum prop(T) = __traits(hasMember, T, "member") && T.member==3; pragma(msg, prop!S1); pragma(msg, prop!S2);

Re: lazy evaluation of logical operators in enum definition

On Monday, 16 April 2018 at 05:57:01 UTC, Shachar Shemesh wrote: Consider the following program: struct S1 { enum member = 3; } struct S2 { enum member = 2; } struct S3 { } enum prop(T) = __traits(hasMember, T, "member") && T.member==3; pragma(msg, prop!S1); pragma(msg, prop!S2);

lazy evaluation of logical operators in enum definition

Consider the following program: struct S1 { enum member = 3; } struct S2 { enum member = 2; } struct S3 { } enum prop(T) = __traits(hasMember, T, "member") && T.member==3; pragma(msg, prop!S1); pragma(msg, prop!S2); pragma(msg, prop!S3); When compiled, it produces: true false

DIP: Binary assignment operators for properties -- Draft Review

The DIP process is on again. I'll be publishing a blog post soon describing the changes and their motivation. In the meantime, the primary candidate to become DIP 1013 [1] needs a good going over for the Draft Review to shake out any structural or technical issues. Please see the new Procedure

[Issue 14489] Deprecate Floating point NCEG operators

https://issues.dlang.org/show_bug.cgi?id=14489 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED

  1   2   3   4   5   6   7   8   >