www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pow Expressions - not worth the juice?

reply Walter Bright <newshound2 digitalmars.com> writes:
https://dlang.org/spec/expression.html#pow_expressions

They're a bit of an oddball feature in D, in that it's the only feature that 
relies on Phobos for its implementation.

Time for it to go?
Feb 02
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 03/02/2026 6:43 AM, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions
 
 They're a bit of an oddball feature in D, in that it's the only feature 
 that relies on Phobos for its implementation.
 
 Time for it to go?


Absolutely not, the implementation can be moved to based as soon as we 
have something like bundles solving binaries.

This is precisely what based is meant to be able to solve.
Feb 02
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 2 February 2026 at 17:48:20 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 03/02/2026 6:43 AM, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions
 
 They're a bit of an oddball feature in D, in that it's the 
 only feature that relies on Phobos for its implementation.
 
 Time for it to go?


 Absolutely not, the implementation can be moved to based as 
 soon as we have something like bundles solving binaries.

 This is precisely what based is meant to be able to solve.


based? bundles solving binaries? Not sure on what these are...
Feb 02
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 03/02/2026 9:52 AM, jmh530 wrote:

 On Monday, 2 February 2026 at 17:48:20 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 03/02/2026 6:43 AM, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the only 
 feature that relies on Phobos for its implementation.

 Time for it to go?


 Absolutely not, the implementation can be moved to based as soon as we 
 have something like bundles solving binaries.

 This is precisely what based is meant to be able to solve.


 
 based? bundles solving binaries? Not sure on what these are...


Based is part of PhobosV3 work, and lives "under" druntime.

For all intents and purposes its a library that will always exist if you 
have D, and will provide things like atomics and bit manipulation.

Bundles is an approach to software/source code distribution, its used on 
osx.

Right now we use a very hard coded approach, that doesn't support based 
or PhobosV3.

If you're not contributing to druntime or compiler you can basically 
ignore it.
Feb 02
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 2 February 2026 at 17:43:45 UTC, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the only 
 feature that relies on Phobos for its implementation.

 Time for it to go?


clearly the solution is to let users define opOverloads anywhere 
and then properly define it as `auto opBinary(string 
op:"^^",T,S)(T t,S s)`
Feb 02
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 2 February 2026 at 17:43:45 UTC, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the only 
 feature that relies on Phobos for its implementation.

 Time for it to go?


No. It's established syntax, please do not break it. It's also 
handy, I sure prefer `a^^b` to `pow(a, b)` and slightly even over 
`a.pow(b)`.

However, there is a case for having power expressions to rewrite 
to a DRuntime symbol instead, even if that symbol then aliases to 
an `extern` function that is implemented in Phobos. Users should 
be able to override that DRuntime symbol, and it should be 
implemented so it only links to Phobos if the default DRuntime 
symbol is actually used - probably means the symbol should be a 
templated.
Feb 02
prev sibling next sibling parent Sergey <kornburn yandex.ru> writes:
On Monday, 2 February 2026 at 17:43:45 UTC, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the only 
 feature that relies on Phobos for its implementation.

 Time for it to go?


Can we instead of continuous breaking freeze for another 6 months 
and fix all regressions that recent releases provided?
Feb 02
prev sibling next sibling parent reply Sam Potter <sfp hush.ai> writes:
On Monday, 2 February 2026 at 17:43:45 UTC, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the only 
 feature that relies on Phobos for its implementation.

 Time for it to go?


Please no.

Operator overloading for ^^ is a really nice quality of life 
improvement for numerical and scientific programming.

All five major numerical programming languages support this: 
MATLAB, Python, Fortran, Julia, and R.
Feb 02
parent reply Lance Bachmeier <no spam.net> writes:
On Monday, 2 February 2026 at 20:23:01 UTC, Sam Potter wrote:

 On Monday, 2 February 2026 at 17:43:45 UTC, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the 
 only feature that relies on Phobos for its implementation.

 Time for it to go?


 Please no.

 Operator overloading for ^^ is a really nice quality of life 
 improvement for numerical and scientific programming.

 All five major numerical programming languages support this: 
 MATLAB, Python, Fortran, Julia, and R.


We should have more operators, not fewer.
Feb 02
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 3 February 2026 at 01:38:03 UTC, Lance Bachmeier 
wrote:

 On Monday, 2 February 2026 at 20:23:01 UTC, Sam Potter wrote:

 On Monday, 2 February 2026 at 17:43:45 UTC, Walter Bright 
 wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the 
 only feature that relies on Phobos for its implementation.

 Time for it to go?


 Please no.

 Operator overloading for ^^ is a really nice quality of life 
 improvement for numerical and scientific programming.

 All five major numerical programming languages support this: 
 MATLAB, Python, Fortran, Julia, and R.


 We should have more operators, not fewer.


I have found that R’s custom infix operators are nice [1]. They 
have a good balance between allowing library writers to be 
expressible, as well as a bit of a warning that "here be dragons".

For those not familiar, putting an R example into a D context it 
would mean you could do something like

```
struct Foo
     double x;
     bool opBinary(string op)(double y)
         if (op == "%divisible%")
     {
         return x % y == 0 ? true : false;
     }
}
```
where the basically the `"op"` can be anything so long as it is 
delimited in a form like "%op%"

It would be even better if you could do something like (to my 
knowledge `opBinary` would need to be a member function).

```
bool opBinary(string op)(double x, double y)
     if (op == "%divisible%")
{
     return x % y == 0 ? true : false;
}
```

[1] https://www.datamentor.io/r-programming/infix-operator
Feb 03
next sibling parent reply user1234 <user1234 12.de> writes:
On Tuesday, 3 February 2026 at 15:11:17 UTC, jmh530 wrote:

 I have found that R’s custom infix operators are nice [1]. They 
 have a good balance between allowing library writers to be 
 expressible, as well as a bit of a warning that "here be 
 dragons".

 For those not familiar, putting an R example into a D context 
 it would mean you could do something like

 ```
 struct Foo
     double x;
     bool opBinary(string op)(double y)
         if (op == "%divisible%")
     {
         return x % y == 0 ? true : false;
     }
 }
 ```
 where the basically the `"op"` can be anything so long as it is 
 delimited in a form like "%op%"

 It would be even better if you could do something like (to my 
 knowledge `opBinary` would need to be a member function).

 ```
 bool opBinary(string op)(double x, double y)
     if (op == "%divisible%")
 {
     return x % y == 0 ? true : false;
 }
 ```

 [1] https://www.datamentor.io/r-programming/infix-operator


So you just avoid the call-expression syntax so that you can put 
spaces between the operands and the operator ? I'm not sure this 
solves any problem. Maybe you can provide enlightning examples ? 
The one from your link is not convincing.
Feb 03
next sibling parent reply user1234 <user1234 12.de> writes:
On Tuesday, 3 February 2026 at 15:23:09 UTC, user1234 wrote:

 So you just avoid the call-expression syntax so that you can 
 put spaces between the operands and the operator ? I'm not sure 
 this solves any problem. Maybe you can provide enlightning 
 examples ? The one from your link is not convincing.


I must add: this brings the topic of defining global operator 
overloads as well. A very old topic in D NG.
Feb 03
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2026 7:24 AM, user1234 wrote:

 I must add: this brings the topic of defining global operator overloads as
well. 
 A very old topic in D NG.


This feature is not in D because it leads to impenetrable code. One terrifying 
example of this is overloading operators such that what looks like ordinary
code 
is actually a regular expression machine.
Feb 03
next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 3 February 2026 at 17:50:12 UTC, Walter Bright wrote:

 On 2/3/2026 7:24 AM, user1234 wrote:

 I must add: this brings the topic of defining global operator 
 overloads as well. A very old topic in D NG.


 This feature is not in D because it leads to impenetrable code. 
 One terrifying example of this is overloading operators such 
 that what looks like ordinary code is actually a regular 
 expression machine.


No, it *enables* impenetrable code; `2^^3` is not impenetrable 
and as you see you instantly got 4 pages of backlash for 
suggesting its removal.

I hate when you break your own rules for your special cases; you 
needed to define an op overload via magic lib, but because your 
the compiler dev you let yourself do it. Do the opposite of what 
your getting backlash here for, *I want that tool*, that will 
bring consistency your looking for.
Feb 03
prev sibling parent Sam Potter <sfp hush.ai> writes:
On Tuesday, 3 February 2026 at 17:50:12 UTC, Walter Bright wrote:

 On 2/3/2026 7:24 AM, user1234 wrote:

 I must add: this brings the topic of defining global operator 
 overloads as well. A very old topic in D NG.


 This feature is not in D because it leads to impenetrable code. 
 One terrifying example of this is overloading operators such 
 that what looks like ordinary code is actually a regular 
 expression machine.


I had a very interesting experience using D for the 
implementation of a math library earlier last year.

Because of D's import rules, I quickly realized that if I wanted 
to have a generic "operator" like `pow` or `intersect` or `abs` 
or whatever else, what actually made the most sense was to have a 
separate file (e.g. "pow.d") where all the `pow` overloads lived. 
That way, if I wanted to use `pow`, the prescription was simple: 
`import pow;`. All of the issues with precedence between imports 
that crop up when you have `pow` littered all over the place 
simply evaporated.

I've since had to rewrite this library in C++ :( :( but I kept 
this organizational choice and have had close to 0 compilation 
errors that originated from ADL weirdness.

Well, you can see where I'm going with this... `^^` is just 
notation for `pow`... Having to define operators *in* a class 
didn't prevent me from doing anything, but if I had been able to 
define them in `opPow.d` (or whatever), I think the design of my 
library would have been even clearer and more rational.

FWIW, in a math library, overloads of `pow` are myriad: are you 
raising an integer to an integer? No, a matrix to a matrix? Oh... 
a diagonal matrix raised to an arbitrary precision rational 
number... Or maybe a polynomial in the Bernstein basis raised to 
a polynomial in the monomial basis...
Feb 04
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 3 February 2026 at 15:23:09 UTC, user1234 wrote:

 [snip]

 ```
 struct Foo
     double x;
     bool opBinary(string op)(double y)
         if (op == "%divisible%")
     {
         return x % y == 0 ? true : false;
     }
 }
 ```
 where the basically the `"op"` can be anything so long as it 
 is delimited in a form like "%op%"

 It would be even better if you could do something like (to my 
 knowledge `opBinary` would need to be a member function).

 ```
 bool opBinary(string op)(double x, double y)
     if (op == "%divisible%")
 {
     return x % y == 0 ? true : false;
 }
 ```

 [1] https://www.datamentor.io/r-programming/infix-operator


 So you just avoid the call-expression syntax so that you can 
 put spaces between the operands and the operator ? I'm not sure 
 this solves any problem. Maybe you can provide enlightning 
 examples ? The one from your link is not convincing.


I was sketching out what a D version of the example from that 
link, not that I would want to do that in D. We have UFCS.

The idea is that you can put anything in within the "op" of 
"%op%", so it's on the user to decide how they want to make use 
of it (or not). R uses "%*%" for matrix multiplication. That's 
more ergonomic than `A.matmul(B)`.
Feb 03
parent reply user1234 <user1234 12.de> writes:
On Tuesday, 3 February 2026 at 15:51:05 UTC, jmh530 wrote:

 On Tuesday, 3 February 2026 at 15:23:09 UTC, user1234 wrote:

 [snip]

 [...]


 So you just avoid the call-expression syntax so that you can 
 put spaces between the operands and the operator ? I'm not 
 sure this solves any problem. Maybe you can provide 
 enlightning examples ? The one from your link is not 
 convincing.


 I was sketching out what a D version of the example from that 
 link, not that I would want to do that in D. We have UFCS.

 The idea is that you can put anything in within the "op" of 
 "%op%", so it's on the user to decide how they want to make use 
 of it (or not). R uses "%*%" for matrix multiplication. That's 
 more ergonomic than `A.matmul(B)`.


Thanks for your reply but that confirms what I initially thought. 
Personally I see a little problem with the surrouding percent 
symbols (i.e not a progress compared to call syntax, they are 
equally unperfect) but essentially that's not a criticism about R 
designers choices. Just not fan you see.
Feb 03
parent reply user1234 <user1234 12.de> writes:
On Tuesday, 3 February 2026 at 16:39:59 UTC, user1234 wrote:

 On Tuesday, 3 February 2026 at 15:51:05 UTC, jmh530 wrote:

 [...]


 Thanks for your reply but that confirms what I initially 
 thought. Personally I see a little problem with the surrouding 
 percent symbols (i.e not a progress compared to call syntax, 
 they are equally unperfect) but essentially that's not a 
 criticism about R designers choices. Just not fan you see.


well to be completly honest, it's nice to be able to write `a %∩% 
b` but the percent syms waste the whole thing I think.
Feb 03
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 3 February 2026 at 17:10:13 UTC, user1234 wrote:

 On Tuesday, 3 February 2026 at 16:39:59 UTC, user1234 wrote:

 On Tuesday, 3 February 2026 at 15:51:05 UTC, jmh530 wrote:

 [...]


 Thanks for your reply but that confirms what I initially 
 thought. Personally I see a little problem with the surrouding 
 percent symbols (i.e not a progress compared to call syntax, 
 they are equally unperfect) but essentially that's not a 
 criticism about R designers choices. Just not fan you see.


 well to be completly honest, it's nice to be able to write `a 
 %∩% b` but the percent syms waste the whole thing I think.


Walter would never go for unlimited overloading.
Feb 03
next sibling parent user1234 <user1234 12.de> writes:
On Tuesday, 3 February 2026 at 17:25:10 UTC, jmh530 wrote:

 On Tuesday, 3 February 2026 at 17:10:13 UTC, user1234 wrote:

 On Tuesday, 3 February 2026 at 16:39:59 UTC, user1234 wrote:

 On Tuesday, 3 February 2026 at 15:51:05 UTC, jmh530 wrote:

 [...]


 Thanks for your reply but that confirms what I initially 
 thought. Personally I see a little problem with the 
 surrouding percent symbols (i.e not a progress compared to 
 call syntax, they are equally unperfect) but essentially 
 that's not a criticism about R designers choices. Just not 
 fan you see.


 well to be completly honest, it's nice to be able to write `a 
 %∩% b` but the percent syms waste the whole thing I think.


 Walter would never go for unlimited overloading.


I would not either, for the simple reason that you would have to 
run the sema of every import known. That breaks a bit the "adhoc" 
compilation model. This would add complexity. For now this is 
simple. Custom type ? let's see if that custom type implements 
the opover. dead simple.
Feb 03
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2026 9:25 AM, jmh530 wrote:

 Walter would never go for unlimited overloading.


Once that gate to hell is opened, we'll never be able to close it.

Just like with macros.

The current operator overloading feature is carefully designed to prevent 
general operator overloading. For example, < <= > >= cannot be individually 
overloaded.
Feb 03
parent reply Lance Bachmeier <no spam.net> writes:
On Tuesday, 3 February 2026 at 18:05:11 UTC, Walter Bright wrote:

 On 2/3/2026 9:25 AM, jmh530 wrote:

 Walter would never go for unlimited overloading.


 Once that gate to hell is opened, we'll never be able to close 
 it.

 Just like with macros.

 The current operator overloading feature is carefully designed 
 to prevent general operator overloading. For example, < <= > >= 
 cannot be individually overloaded.


If you think that's bad, wait until you see the ugly mess that 
can be made with pointers, metaprogramming, and templates.
Feb 03
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2026 11:38 AM, Lance Bachmeier wrote:

 If you think that's bad, wait until you see the ugly mess that can be made
with 
 pointers, metaprogramming, and templates.


I did try to reduce the incidence of awfulness with templates with a (much) 
cleaner design than C++, but still templates are overused.
Feb 03
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 3 February 2026 at 17:10:13 UTC, user1234 wrote:

 On Tuesday, 3 February 2026 at 16:39:59 UTC, user1234 wrote:

 On Tuesday, 3 February 2026 at 15:51:05 UTC, jmh530 wrote:

 [...]


 Thanks for your reply but that confirms what I initially 
 thought. Personally I see a little problem with the surrouding 
 percent symbols (i.e not a progress compared to call syntax, 
 they are equally unperfect) but essentially that's not a 
 criticism about R designers choices. Just not fan you see.


 well to be completly honest, it's nice to be able to write `a 
 %∩% b` but the percent syms waste the whole thing I think.



#divisible
anywhere in D. How can people live with that terrible R syntax is 
beyond me, but hey - matter of taste I guess! This could allow 
alternative syntax for some common logic operators (`foo #ge
as alternative to `foo >= 2`)...
Feb 03
next sibling parent Lance Bachmeier <no spam.net> writes:
On Tuesday, 3 February 2026 at 17:29:44 UTC, Dejan Lekic wrote:



 #divisible
 anywhere in D. How can people live with that terrible R syntax 
 is beyond me, but hey - matter of taste I guess! This could 
 allow alternative syntax for some common logic operators (`foo 
 #ge


R didn't have many alternatives, as it's a numerical language, so 
they already used all the operators for other things. It does 
make it stand out, which is nice for readability once you are 
experienced with the language.
Feb 03
prev sibling parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 3 February 2026 at 17:29:44 UTC, Dejan Lekic wrote:

 How can people live with that terrible R syntax is beyond me, 
 but hey - matter of taste I guess! This could allow alternative 
 syntax for some common logic operators (`foo #ge
 alternative to `foo >= 2`)...


This feature is not very often used.
I could remember only `%>%` which was moved to `|>` in newer 
versions.
And `%in%` which you could use as `if (x %in% c("foo", "bar")`

But R is pretty specific because of its roots with S and Lisp =)
Feb 03
prev sibling next sibling parent Lance Bachmeier <no spam.net> writes:
On Tuesday, 3 February 2026 at 15:11:17 UTC, jmh530 wrote:

 On Tuesday, 3 February 2026 at 01:38:03 UTC, Lance Bachmeier 
 wrote:

 On Monday, 2 February 2026 at 20:23:01 UTC, Sam Potter wrote:

 On Monday, 2 February 2026 at 17:43:45 UTC, Walter Bright 
 wrote:

 https://dlang.org/spec/expression.html#pow_expressions

 They're a bit of an oddball feature in D, in that it's the 
 only feature that relies on Phobos for its implementation.

 Time for it to go?


 Please no.

 Operator overloading for ^^ is a really nice quality of life 
 improvement for numerical and scientific programming.

 All five major numerical programming languages support this: 
 MATLAB, Python, Fortran, Julia, and R.


 We should have more operators, not fewer.


 I have found that R’s custom infix operators are nice [1]. They 
 have a good balance between allowing library writers to be 
 expressible, as well as a bit of a warning that "here be 
 dragons".

 For those not familiar, putting an R example into a D context 
 it would mean you could do something like

 ```
 struct Foo
     double x;
     bool opBinary(string op)(double y)
         if (op == "%divisible%")
     {
         return x % y == 0 ? true : false;
     }
 }
 ```
 where the basically the `"op"` can be anything so long as it is 
 delimited in a form like "%op%"

 It would be even better if you could do something like (to my 
 knowledge `opBinary` would need to be a member function).

 ```
 bool opBinary(string op)(double x, double y)
     if (op == "%divisible%")
 {
     return x % y == 0 ? true : false;
 }
 ```

 [1] https://www.datamentor.io/r-programming/infix-operator


An important decision they made is that you can have custom 
operators, but you can't change the precedence.[1] You can add 
parens to your code if you want to customize precedence. There 
are really no downsides to custom operators.

[1] 
https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Infix-and-prefix-operators
Feb 03
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2026 7:11 AM, jmh530 wrote:

 where the basically the `"op"` can be anything so long as it is delimited in a 
 form like "%op%"


In D that would be like:
```d
x.op(y)
```
Feb 03
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 04/02/2026 6:46 AM, Walter Bright wrote:

 On 2/3/2026 7:11 AM, jmh530 wrote:

 where the basically the `"op"` can be anything so long as it is 
 delimited in a form like "%op%"


 
 In D that would be like:
 ```d
 x.op(y)
 ```


"op" there isn't meant to be a valid identifier.

It would translate to: ``a.opBinary!"op"(b)`` or ``a.opUnary!"op"``

I don't like this delineated approach, but there are tables for Unicode 
math binary/unary op's around.

Main issue is a character can be both.

However given D is not a mathematical language, its introduction is 
questionable at best.
Feb 03
parent reply user1234 <user1234 12.de> writes:
On Tuesday, 3 February 2026 at 18:34:01 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 04/02/2026 6:46 AM, Walter Bright wrote:

 On 2/3/2026 7:11 AM, jmh530 wrote:

 where the basically the `"op"` can be anything so long as it 
 is delimited in a form like "%op%"


 
 In D that would be like:
 ```d
 x.op(y)
 ```


 "op" there isn't meant to be a valid identifier.

 It would translate to: ``a.opBinary!"op"(b)`` or 
 ``a.opUnary!"op"``

 I don't like this delineated approach, but there are tables for 
 Unicode math binary/unary op's around.

 Main issue is a character can be both.

 However given D is not a mathematical language, its 
 introduction is questionable at best.


I see indeed a lot of potential disapoinment.

people wants to be able to write `a ∩ b`. But `∩` is not an 
regulatory identifier character (I remember you've recently 
worked on that problem). The R lang solution would not even work. 
`a "∩" b` or something... just like the workaround in R.
Feb 03
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 04/02/2026 7:55 AM, user1234 wrote:

 On Tuesday, 3 February 2026 at 18:34:01 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 04/02/2026 6:46 AM, Walter Bright wrote:

 On 2/3/2026 7:11 AM, jmh530 wrote:

 where the basically the `"op"` can be anything so long as it is 
 delimited in a form like "%op%"


 In D that would be like:
 ```d
 x.op(y)
 ```


 "op" there isn't meant to be a valid identifier.

 It would translate to: ``a.opBinary!"op"(b)`` or ``a.opUnary!"op"``

 I don't like this delineated approach, but there are tables for 
 Unicode math binary/unary op's around.

 Main issue is a character can be both.

 However given D is not a mathematical language, its introduction is 
 questionable at best.


 
 I see indeed a lot of potential disapoinment.
 
 people wants to be able to write `a ∩ b`. But `∩` is not an regulatory 
 identifier character (I remember you've recently worked on that 
 problem). The R lang solution would not even work. `a "∩" b` or 
 something... just like the workaround in R.


Identifiers have nothing to do with this, its a mathematical operator 
just like ``|`` is.

Different set of tables (in this case hard coded into parser).
Feb 03
prev sibling parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 3 February 2026 at 18:55:42 UTC, user1234 wrote:

 people wants to be able to write `a ∩ b`. But `∩` is not an 
 regulatory identifier character (I remember you've recently 
 worked on that problem). The R lang solution would not even 
 work. `a "∩" b` or something... just like the workaround in R.


Julia supports it :)

```julia
a = Set([1,2,3])
b = Set([3,4,5])

c = a ∩ b
```
Feb 03
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 3 February 2026 at 17:46:40 UTC, Walter Bright wrote:

 On 2/3/2026 7:11 AM, jmh530 wrote:

 where the basically the `"op"` can be anything so long as it 
 is delimited in a form like "%op%"


 In D that would be like:
 ```d
 x.op(y)
 ```


According to D grammar [1]:


 Identifiers start with a letter, _, or universal alpha, and are 
 followed by any number of
 letters, _, digits, or universal alphas. Universal alphas are 
 as defined in ISO/IEC
 9899:1999(E) Appendix D of the C99 Standard.


which places limits on what "op" can be. That's why I elsewhere 
said that you would write something like `x.matmul(y)` in D 
whereas in R you would write `x %*% y` (Matlab's even more 
convenient with `x * y`, but they use `x .* y` for element-wise 
multiplication, which I like but deviates too much from C for D 
to adopt I think).

[1] https://dlang.org/spec/lex.html#Identifier
Feb 03
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 2/2/26 18:43, Walter Bright wrote:

 https://dlang.org/spec/expression.html#pow_expressions
 
 They're a bit of an oddball feature in D,


No. An actual example of an oddball "feature" is how D handles closure 
allocation in loops in that its implementation and resulting behavior is 
completely and utterly broken in a way that goes way below and beyond 
even the plethora of slightly different bad designs that exist in other 
popular languages.


 in that it's the only feature 
 that relies on Phobos for its implementation.
 ...


Well, then maybe the implementation should be changed.


 Time for it to go?


Absolutely not.

I suggest focusing attention on actual problems instead of continuously 
trying to break obvious quality-of-life features that together add up to 
making D great.

Binary literals and opBinary!"^^" ftw.

I know it's much trickier to fix hard problems instead of gratuitously 
breaking simple things that already work, but I really think that's just 
also where most of the juice is.
Feb 02
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 2/3/26 00:23, Timon Gehr wrote:

 

 in that it's the only feature that relies on Phobos for its 
 implementation.
 ...


 
 Well, then maybe the implementation should be changed.


As Adam points out: https://github.com/dlang/dmd/pull/14297
Feb 02
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/2/2026 3:43 PM, Timon Gehr wrote:

 Well, then maybe the implementation should be changed.


 
 As Adam points out: https://github.com/dlang/dmd/pull/14297


Putting it in druntime is a reasonable way to go.
Feb 03
prev sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Feb 02, 2026 at 09:43:45AM -0800, Walter Bright via Digitalmars-d wrote:

 https://dlang.org/spec/expression.html#pow_expressions
 
 They're a bit of an oddball feature in D, in that it's the only
 feature that relies on Phobos for its implementation.
 
 Time for it to go?


No, please don't.  Being able to write x^^y instead of ugliness like
pow(x,y) that you have to in other languages is a very nice QoL feature
in D.  Why are we trying to make D harder to use, instead of easier?


T

-- 
People tell me that I'm paranoid, but they're just out to get me.
Feb 03