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 mean,
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
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` instanc
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 name
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 that
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 a
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.
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
operat
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 templ
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 cannot b
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 &
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 &&
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 lists
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
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 &&
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".
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
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 lists
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 operat
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 lists
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 t
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.
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 t
Which operators cannot be overloaded and why not?
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, I
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
>
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++
operato
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.
[...]
F
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
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
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
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
operato
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).
quot;+"(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
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 th
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
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?
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
op
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-
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 flo
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
--
"Rea
ns has 'not comparible' state?
I think 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 che
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
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.
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
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 p
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 pre
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?
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
On Monday, December 11, 2017 19:28:47 rumbu via Digitalmars-d-learn wrote:
> Is there any way to overload specific floating point operators?
> https://dlang.org/spec/expression.html#floating-point-comparisons
If those haven't been deprecated yet, they almost certainly will be. It was
d
On 12/11/2017 08:28 PM, rumbu wrote:
Is there any way to overload specific floating point operators?
https://dlang.org/spec/expression.html#floating-point-comparisons
Those don't seem to work anymore. At least since 2.073, dmd rejects them
and says to use std.math.isNaN instead. Looks
Is there any way to overload specific floating point operators?
https://dlang.org/spec/expression.html#floating-point-comparisons
I'm using a decimal data type (a struct) and one of the possible
values is NaN, that's why I need these operators.
I know also that this also was discuss
On 2017-05-02 18:55, TheGag96 wrote:
On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote:
From that link:
"Note that dmd currently does not comply with left to right evaluation
of function arguments and AssignExpression".
This is something I've never understood. Why doesn't DMD impl
On 2017-05-02 09:42, Jacob Carlborg wrote:
On 2017-05-02 01:27, Faux Amis wrote:
To me, this [2] suggests otherwise ;)
Or am I missing something?
[2] https://dlang.org/spec/expression.html#order-of-evaluation
From that link:
"Note that dmd currently does not comply with left to right evalu
On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote:
From that link:
"Note that dmd currently does not comply with left to right
evaluation of function arguments and AssignExpression".
This is something I've never understood. Why doesn't DMD
implement the behavior their own language
On 2017-05-02 01:27, Faux Amis wrote:
To me, this [2] suggests otherwise ;)
Or am I missing something?
[2] https://dlang.org/spec/expression.html#order-of-evaluation
From that link:
"Note that dmd currently does not comply with left to right evaluation
of function arguments and AssignExpres
On Monday, 1 May 2017 at 21:04:15 UTC, bachmeier wrote:
On Monday, 1 May 2017 at 18:16:48 UTC, Era Scarecrow wrote:
Reminds me... was the unsigned shift >>> ever fixed?
What was wrong with it?
Doing a broad test I'm seeing an issue with short & byte
versions... Course that's probably due t
Not sure if this is still the case. But this [1] suggests that D doesn't
have an evaluation order defined but Java does.
[1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder
To me, this [2] suggests otherwise ;)
Or am I missing something?
[2] https://dlang.org/spec/expression.ht
On Monday, 1 May 2017 at 18:16:48 UTC, Era Scarecrow wrote:
On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:
It's the same code in D. It extracts consecutive bits in x12
and x13 (and maskxx), put them at the beginning (right shift)
and add them.
Reminds me... was the unsigned shift >>
On Monday, 1 May 2017 at 19:06:36 UTC, Jacob Carlborg wrote:
Not sure if this is still the case. But this [1] suggests that
D doesn't have an evaluation order defined but Java does.
[1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder
That's good to know but shouldn't be an issue
On 2017-05-01 17:45, bachmeier wrote:
I'm porting a small piece of Java code into D, but I've run into this:
int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13) << 7) +
(x13 >>> 24);
I have a basic understanding of those operators in
On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:
It's the same code in D. It extracts consecutive bits in x12
and x13 (and maskxx), put them at the beginning (right shift)
and add them.
Reminds me... was the unsigned shift >>> ever fixed?
On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:
It's the same code in D. It extracts consecutive bits in x12
and x13 (and maskxx), put them at the beginning (right shift)
and add them.
Thanks.
On Monday, 1 May 2017 at 15:45:00 UTC, bachmeier wrote:
I'm porting a small piece of Java code into D, but I've run
into this:
int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13)
<< 7) + (x13 >>> 24);
I have a basic understand
I'm porting a small piece of Java code into D, but I've run into
this:
int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13)
<< 7) + (x13 >>> 24);
I have a basic understanding of those operators in both
languages, but I can't
On Thursday, 9 March 2017 at 23:50:04 UTC, XavierAP wrote:
The same way as T.foo() is lowered to foo(T) if no such member
is defined inside the type.
No.
But wrapping in a struct with alias this lets you extend them
pretty easily too.
The same way as T.foo() is lowered to foo(T) if no such member is
defined inside the type. It would allow me to extend 3rd party
types with operator notation without wrapping them.
After trying and reading the specification, looks like nuts, but
just wanted to confirm. Thx
On Wednesday, 18 June 2014 at 05:49:30 UTC, Ali Çehreli wrote:
Can you come up with a D library solution to the following
C++11 proposal:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3950.html
did this years ago (or something similar, at least):
https://bitbucket.org/ariovist
On 06/18/14 07:49, Ali Çehreli via Digitalmars-d-learn wrote:
> The idea is to be able to have standard comparison behavior for structs
> without boilerplate. For example, if the ordering should consider all members
> of the following struct one after the other (first 'i', then 'l', and finally
Can you come up with a D library solution to the following C++11 proposal:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3950.html
The idea is to be able to have standard comparison behavior for structs
without boilerplate. For example, if the ordering should consider all
members
On Mon, Dec 30, 2013 at 05:34:10AM +0100, Marco Leise wrote:
> Am Sat, 28 Dec 2013 15:24:31 +
> schrieb "Dicebot" :
>
> > AFAIK it is intentionally banned to constrain operator
> > overloading abuse.
>
> That and it makes the compiler faster.
[...]
And discourages writing unreadable code li
Am Sat, 28 Dec 2013 15:24:31 +
schrieb "Dicebot" :
> AFAIK it is intentionally banned to constrain operator
> overloading abuse.
That and it makes the compiler faster.
--
Marco
at
>implements
>elementwise arithmetic as opposed to the normal arithmetic.
>
>The operators would return instances of Matrix, not
>elementWise, to
>avoid accidentally spilling a Matrix.ElementWise struct in to
>ensuing
>code unintentionally. With a shorter alias it's rathe
tic as opposed to the normal arithmetic.
> >
> >The operators would return instances of Matrix, not elementWise, to
> >avoid accidentally spilling a Matrix.ElementWise struct in to ensuing
> >code unintentionally. With a shorter alias it's rather neat.
> >
> >auto
On 28/12/13 18:50, John Colvin wrote:
how about:
a.elementWise * b
where a.elementWise returns a wrapper struct around a that implements
elementwise arithmetic as opposed to the normal arithmetic.
The operators would return instances of Matrix, not elementWise, to avoid
accidentally spilling
Wise * b
where a.elementWise returns a wrapper struct around a that
implements elementwise arithmetic as opposed to the normal
arithmetic.
The operators would return instances of Matrix, not elementWise,
to avoid accidentally spilling a Matrix.ElementWise struct in to
ensuing code unintentionally. With
On 28/12/13 16:24, Dicebot wrote:
AFAIK it is intentionally banned to constrain operator overloading abuse.
Ahh, makes sense. But isn't it possible to do something with templates that
would allow for something like,
auto a = matrix(...);
auto b = matrix(...);
auto c = ElementWi
AFAIK it is intentionally banned to constrain operator
overloading abuse.
Is there any way with D to define custom binary operators for user-defined
types? I'm thinking of examples like MATLAB/Octave using the operators .+, .-,
etc. to define element-wise addition, subtraction, etc. of matrices.
AFAICS just doing something like
auto opBinary(string op,
On Wednesday, 7 August 2013 at 21:08:24 UTC, Tobias Pankrath
wrote:
import std.stdio;
struct ArrayTypeA {
int[12] data;
size_t length() { return 12; }
auto opSlice(size_t s, size_t e) { return data[s .. e];
}
}
struct ArrayTypeB {
int[24] data;
auto op
import std.stdio;
struct ArrayTypeA {
int[12] data;
size_t length() { return 12; }
auto opSlice(size_t s, size_t e) { return data[s .. e]; }
}
struct ArrayTypeB {
int[24] data;
auto opSlice(size_t s, size_t e) { return data[s.. e]; }
size_t lengt
tweigh the penalty.
Not for me, and I suspect others too.
These operators are self-documenting, no one will need to
look up 'and'
I can't recall ever being confused by &&.. in fact, I got my
first programming job (an apprentice position) by describing
some C code
o.
These operators are self-documenting, no one will need to look up 'and'
I can't recall ever being confused by &&.. in fact, I got my first
programming job (an apprentice position) by describing some C code (a
language I had never used/seen before) using && and I
owing what any given code sample does, and not have to look
up alternate syntax etc.
R
Up to a point I'd certainly agree with that, however in this
case I think the advantages outweigh the penalty.
Not for me, and I suspect others too.
These operators are self-documenting, no one will ne
ok up alternate syntax etc.
R
Up to a point I'd certainly agree with that, however in this case I
think the advantages outweigh the penalty.
Not for me, and I suspect others too.
These operators are self-documenting, no one will need to look up 'and'
I can't recall ever
certainly agree with that, however in this case
I think the advantages outweigh the penalty. These operators are
self-documenting, no one will need to look up 'and' and gain
readability, language accessibility and beauty.
On Friday, 31 May 2013 at 10:21:19 UTC, Regan Heath wrote:
Until this thread I didn't even know they existed..
Same.
I use them every day in python, but I had no idea they were in C++
Tbh they annoy me in python, although that's just my C background
showing.
On Fri, May 31, 2013 at 4:12 PM, Minas Mina
wrote:
> They are more noisy for non-English talking persons.
Um and the rest of the D keywords are in what language?!
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
e to write
in English.
In C code it's not uncommon to write "&" where you meant "&&" by
mistake and vice versa (so common that all the lint tools I know
of have rules to spot such kind of bug). And for most kinds of
not low-level programming bitwise operators
On Thursday, 30 May 2013 at 16:48:33 UTC, bearophile wrote:
Shriramana Sharma:
Hello. I have always loved the readability of C++'s
and/or/not/xor
word-like logical operators but It doesn't seem to be
available in D.
and/or/not are less visually noisy, they look better than
On Fri, 31 May 2013 02:41:14 +0100, Shriramana Sharma
wrote:
Thanks to all who replied.
On Thu, May 30, 2013 at 10:18 PM, bearophile
wrote:
But Walter refused them time ago on the basis that no one uses them in
C++.
So you can ask for them in the main D newsgroup, but I don't think yo
On Thu, 30 May 2013 18:57:37 +0100, ixid wrote:
On Thursday, 30 May 2013 at 16:30:12 UTC, Iain Buclaw wrote:
On Thursday, 30 May 2013 at 16:18:44 UTC, Shriramana Sharma wrote:
Hello. I have always loved the readability of C++'s and/or/not/xor
word-like logical operators but It doesn&#
Ali Çehreli:
I don't have a preference on the topic but it would still be
incomplete, right? There are many other operators that don't
have keywords.
Beside the && || ! I think it's much better to not replace the
other operators with keywords.
Perhaps that's
therwise
why
would there be a separate C header ever since 1990 for that:
http://en.wikipedia.org/wiki/Iso646.h
I agree that we should retain the old operators for C
compatibility
but really at least the basic and/or/not/xor keywords should be
provided.
I prefer the Python design here, it us
in C++ since 1997. I have read a lot of books
(mostly on C++), frequented the C++ newsgroups for years and years, and
did work at many C and C++ companies. I have never seen those keywords used.
> I agree that we should retain the old operators for C compatibility
> but really at least the b
header ever since 1990 for that:
http://en.wikipedia.org/wiki/Iso646.h
I agree that we should retain the old operators for C compatibility
but really at least the basic and/or/not/xor keywords should be
provided.
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
On Thursday, 30 May 2013 at 16:18:44 UTC, Shriramana Sharma wrote:
Hello. I have always loved the readability of C++'s
and/or/not/xor
word-like logical operators but It doesn't seem to be available
in D.
Isn't this possible in D? I tried doing:
alias && and ;
impor
On Thursday, 30 May 2013 at 16:30:12 UTC, Iain Buclaw wrote:
On Thursday, 30 May 2013 at 16:18:44 UTC, Shriramana Sharma
wrote:
Hello. I have always loved the readability of C++'s
and/or/not/xor
word-like logical operators but It doesn't seem to be
available in D.
Isn't this p
Shriramana Sharma:
Hello. I have always loved the readability of C++'s
and/or/not/xor
word-like logical operators but It doesn't seem to be available
in D.
and/or/not are less visually noisy, they look better than the
ugly &&/||/! of C/C++/D, and it's much less ea
On 2013-05-30, 13:56, Shriramana Sharma wrote:
Hello. I have always loved the readability of C++'s and/or/not/xor
word-like logical operators but It doesn't seem to be available in D.
Isn't this possible in D? I tried doing:
alias && and ;
import std.stdio ;
void ma
1 - 100 of 153 matches
Mail list logo
