On Wednesday, 28 September 2016 at 01:18:58 UTC, Minty Fresh
wrote:
Currently, D offers fine grained overloading for most of the
unary and arithmetic binary operators, but at some point a
decision was made to lump together all of the relational
operators (and if necessary, the equality
On Saturday, 1 October 2016 at 17:53:44 UTC, Russel Winder wrote:
On Sat, 2016-10-01 at 14:55 +, Chris Wright via
Digitalmars-d wrote:
Groovy doesn't allow you to overload comparison operators
individually,
and probably most JVM languages likewise. This is to retain
compatibility
with
On Sat, 2016-10-01 at 14:55 +, Chris Wright via Digitalmars-d
wrote:
> Groovy doesn't allow you to overload comparison operators
> individually,
> and probably most JVM languages likewise. This is to retain
> compatibility
> with Java, which has `.compareTo()` instead of `isLessThan()` etc.
On Friday, 30 September 2016 at 23:31:19 UTC, Sai wrote:
Genuine question: In the post Java languages, how many
languages allowed unrestricted operator overloading and did
that cause any similar mess?
Thanks in advance for any answers.
Although there maybe a bit of bias here, but I'd say
On Friday, 30 September 2016 at 22:38:07 UTC, Walter Bright wrote:
On 9/30/2016 1:14 PM, Minty Fresh wrote:
Metathesiophobia
Repeatedly suggesting people who don't agree with you have
mental disorders does not advance your case and is not
appreciated here.
Metathesiophobia is not a mental
On Fri, 30 Sep 2016 19:33:33 +, pineapple wrote:
> How many people have to state it how many times in how many different
> ways before it gets through? These are stupid goals. They reflect
> intention that has no basis in reason, that has no basis in reality,
> that is a blindly-enforced
On Fri, 30 Sep 2016 23:31:19 +, Sai wrote:
> Genuine question: In the post Java languages, how many languages allowed
> unrestricted operator overloading and did that cause any similar mess?
Groovy doesn't allow you to overload comparison operators individually,
and probably most JVM
On Saturday, 1 October 2016 at 07:13:39 UTC, Martin Nowak wrote:
The fact that it's not possible to overload < but have to use
the ternary opCmp is even a performance problem. All std
algorithms only use less as a predicate, leading to lots of
unnecessary cycles when e.g. sorting UDTs.
On
On 10/1/16 7:33 AM, Andrei Alexandrescu wrote:
On 10/1/16 3:13 AM, Martin Nowak wrote:
The fact that it's not possible to overload < but have to use the
ternary opCmp is even a performance problem. All std algorithms only use
less as a predicate, leading to lots of unnecessary cycles when e.g.
On 10/1/16 3:13 AM, Martin Nowak wrote:
The fact that it's not possible to overload < but have to use the
ternary opCmp is even a performance problem. All std algorithms only use
less as a predicate, leading to lots of unnecessary cycles when e.g.
sorting UDTs.
I've also been often annoyed by
On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright
wrote:
On 9/28/2016 6:58 AM, Timon Gehr wrote:
An excellent example of that is the std.regex package.
It's actually a bad example, because it is irrelevant: it is
obviously a bad
idea to implement regex using operator overloading,
On Fri, 2016-09-30 at 23:31 +, Sai via Digitalmars-d wrote:
> Genuine question: In the post Java languages, how many languages
> allowed unrestricted operator overloading and did that cause any
> similar mess?
It is not feasible to provide a count, as there is always another
language one
On Fri, 2016-09-30 at 21:43 +, Dominikus Dittes Scherkl via
Digitalmars-d wrote:
> But operator overloading doesn't increase the language
> expressiveness.
Expressiveness is not a metric, there isn't even a partial order, it is
a qualitative thing, thus personal to a great extent. What I
On Fri, 2016-09-30 at 15:38 -0700, Walter Bright via Digitalmars-d
wrote:
> A more productive way forward is for you (and those who agree with
> you) to
> prepare a formal DIP and submit it. It's the way significant language
> change
> proposals are done.
But is the effort worth it? Will the
On Friday, 30 September 2016 at 22:38:07 UTC, Walter Bright wrote:
A more productive way forward is for you (and those who agree
with you) to prepare a formal DIP and submit it. It's the way
significant language change proposals are done.
A good idea.
I have written a rough initial draft for
On 01.10.2016 01:31, Sai wrote:
I understand the concern of possible mess due to unrestricted use of
operator overloading (like C++).
C++ does it in std.
On 30.09.2016 23:43, Dominikus Dittes Scherkl wrote:
On Friday, 30 September 2016 at 09:55:36 UTC, pineapple wrote:
On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis wrote:
Except that it kind of is. It's an example of a language allowing you
to mess with too much and make it so
a.isLessThan(b)
I understand the concern of possible mess due to unrestricted use
of operator overloading (like C++). Java has clearly driven the
point home by banning the operator overloading altogether.
Genuine question: In the post Java languages, how many languages
allowed
On 30.09.2016 22:14, Andrei Alexandrescu wrote:
On 09/30/2016 03:18 PM, Timon Gehr wrote:
On 30.09.2016 21:02, Timon Gehr wrote:
On 30.09.2016 03:15, Chris Wright wrote:
...
Wouldn't that be fun?
Certainly.
On a related note:
alias Seq(T...)=T;
struct S{
int x;
S
On 9/30/2016 1:14 PM, Minty Fresh wrote:
Metathesiophobia
Repeatedly suggesting people who don't agree with you have mental disorders does
not advance your case and is not appreciated here.
A more productive way forward is for you (and those who agree with you) to
prepare a formal DIP and
On Friday, 30 September 2016 at 09:55:36 UTC, pineapple wrote:
On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis
wrote:
Except that it kind of is. It's an example of a language
allowing you to mess with too much and make it so that it
doesn't function as expected, which is what
On 09/30/2016 03:18 PM, Timon Gehr wrote:
On 30.09.2016 21:02, Timon Gehr wrote:
On 30.09.2016 03:15, Chris Wright wrote:
...
Wouldn't that be fun?
Certainly.
On a related note:
alias Seq(T...)=T;
struct S{
int x;
S opBinary(string op:"+",T...)(T args){
S r=this;
On Friday, 30 September 2016 at 19:46:35 UTC, bachmeier wrote:
Claiming that operator overloading only applies to a specific
user-defined type makes it worse. Having it work one way for
three types, a different way for four other types, and a third
way for yet another type doesn't sound like a
On Friday, 30 September 2016 at 01:07:49 UTC, Chris Wright wrote:
The perl example is a line of code buried somewhere that
changes the meaning of the rest of the code. Operator
overloading is restricted to a specific user-defined type. With
such a dramatic difference in the scope of the
On Friday, 30 September 2016 at 16:25:45 UTC, Jonathan M Davis
wrote:
But if you or anyone else wants to do wacky stuff with
overloaded operators that is not consistent with the built-in
types, you're free to do so within how D's overloaded operators
work. You're just not going to be able to
On 30.09.2016 21:02, Timon Gehr wrote:
On 30.09.2016 03:15, Chris Wright wrote:
...
Wouldn't that be fun?
Certainly.
On a related note:
alias Seq(T...)=T;
struct S{
int x;
S opBinary(string op:"+",T...)(T args){
S r=this;
foreach(a;args) r.x+=a;
return
On 30.09.2016 18:11, Jonathan M Davis via Digitalmars-d wrote:
Regardless, D already has a lot of powerful stuff in it, much of which will
allow you to blow your foot off if you're really inclined to. The overloaded
operators just so happened to be implemented in a way that doesn't let you
blow
On 30.09.2016 03:15, Chris Wright wrote:
On Thu, 29 Sep 2016 10:41:38 +0200, Timon Gehr wrote:
On 29.09.2016 06:15, Walter Bright wrote:
On 9/28/2016 1:40 PM, Timon Gehr wrote:
(This is NOT expression templates.)
Right, but it's an enabler of expression templates. Discussion of more
On Friday, September 30, 2016 12:31:45 Minty Fresh via Digitalmars-d wrote:
>
> It's up to the developer to ensure that their code works
> correctly with existing facilities, not the language. I can
> already write code that will work in amazing and ridiculous ways
> with generic code in the
On Friday, September 30, 2016 09:55:36 pineapple via Digitalmars-d wrote:
> On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis
>
> wrote:
> > Except that it kind of is. It's an example of a language
> > allowing you to mess with too much and make it so that it
> > doesn't function as
On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis
wrote:
Except that it kind of is. It's an example of a language
allowing you to mess with too much and make it so that it
doesn't function as expected, which is what happens when you
overload operators to act in a way
On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis
wrote:
Except that it kind of is. It's an example of a language
allowing you to mess with too much and make it so that it
doesn't function as expected, which is what happens when you
overload operators to act in a way inconsistent
On Thu, 29 Sep 2016 10:41:38 +0200, Timon Gehr wrote:
> On 29.09.2016 06:15, Walter Bright wrote:
>> On 9/28/2016 1:40 PM, Timon Gehr wrote:
>>> (This is NOT expression templates.)
>>
>> Right, but it's an enabler of expression templates. Discussion of more
>> powerful operator overloading cannot
On Thu, 29 Sep 2016 17:50:54 -0700, Jonathan M Davis via Digitalmars-d
wrote:
> Except that it kind of is. It's an example of a language allowing you to
> mess with too much and make it so that it doesn't function as expected,
> which is what happens when you overload operators to act in a way
>
On Thursday, September 29, 2016 22:37:51 Minty Fresh via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 22:27:50 UTC, bachmeier wrote:
> > You're looking for https://www.perl.org/ That's a highly viable
> > language, where you can do things like bury $[ = 1 somewhere in
> > your code to
On Thursday, 29 September 2016 at 22:37:51 UTC, Minty Fresh wrote:
On Thursday, 29 September 2016 at 22:27:50 UTC, bachmeier wrote:
You're looking for https://www.perl.org/ That's a highly
viable language, where you can do things like bury $[ = 1
somewhere in your code to change from
On Thursday, 29 September 2016 at 22:27:50 UTC, bachmeier wrote:
You're looking for https://www.perl.org/ That's a highly viable
language, where you can do things like bury $[ = 1 somewhere in
your code to change from 0-indexing to 1-indexing of arrays.
They take pride in unpredictable,
On Thursday, 29 September 2016 at 20:16:00 UTC, pineapple wrote:
I repeat: Your thinking like this limits D's viability for
real-world code.
You're looking for https://www.perl.org/ That's a highly viable
language, where you can do things like bury $[ = 1 somewhere in
your code to change
On Thursday, September 29, 2016 20:16:00 pineapple via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
>
> wrote:
> > The reality of the matter is that D's operator overloading was
> > designed specifically so that you could overload the built-in
> >
On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
wrote:
The reality of the matter is that D's operator overloading was
designed specifically so that you could overload the built-in
operators to be used with your own types so that they could act
like the built-in types. It was
On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
wrote:
The language can't stop you from doing at least some arbitrary
stuff with them (like making + do subtraction), but the whole
goal was for user-defined types to be able to act like the
built-in types, and as such, it would
On 29.09.2016 18:41, Sai wrote:
I.e. you can overload '+' to do bad things. Yes, you can, and as I
replied upthread that can be done because there's no way to prevent
that while having operator overloading at all.
But that is not justification for allowing such disasters for the
comparison
On Thursday, September 29, 2016 19:11:55 pineapple via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 18:38:42 UTC, Jonathan M Davis
>
> wrote:
> > You just can't use overloaded operators for it, since it would
> > not be in line with what the operators are supposed to mean and
> > be
On Thursday, 29 September 2016 at 19:11:55 UTC, pineapple wrote:
Relinquish the notion that you or anyone can have the slightest
idea what any language feature is "supposed to mean and be used
for".
Basically what led to D's CTFE implementation in the first place,
IIRC.
On Thursday, 29 September 2016 at 18:38:42 UTC, Jonathan M Davis
wrote:
You just can't use overloaded operators for it, since it would
not be in line with what the operators are supposed to mean and
be used for.
This is not a valid argument because what an operator is
"supposed to mean" is up
On Thursday, 29 September 2016 at 18:38:42 UTC, Jonathan M Davis
wrote:
Then you could always do something like a.myOp!"<"(b) and
a.myOp!">="(b) if you still want to have the operator in there
somewhere. You can name the functions whatever you want. You
just can't use overloaded operators
On Thursday, September 29, 2016 18:14:22 Minty Fresh via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 18:07:37 UTC, Russel Winder
>
> wrote:
> > On Thu, 2016-09-29 at 10:52 -0700, Walter Bright via
> >
> > Digitalmars-d wrote:
> >> On 9/29/2016 9:41 AM, Sai wrote:
> >> > If I
On Thursday, 29 September 2016 at 18:07:37 UTC, Russel Winder
wrote:
On Thu, 2016-09-29 at 10:52 -0700, Walter Bright via
Digitalmars-d wrote:
On 9/29/2016 9:41 AM, Sai wrote:
>
> If I understand the issue correctly, one will not be able to
> overload <=, >, etc
> for symbolic math, like CAS
On Thu, 2016-09-29 at 10:52 -0700, Walter Bright via Digitalmars-d
wrote:
> On 9/29/2016 9:41 AM, Sai wrote:
> >
> > If I understand the issue correctly, one will not be able to
> > overload <=, >, etc
> > for symbolic math, like CAS (mimicking mathematica for example),
> > how can I do it
> >
On 9/29/2016 9:41 AM, Sai wrote:
If I understand the issue correctly, one will not be able to overload <=, >, etc
for symbolic math, like CAS (mimicking mathematica for example), how can I do it
now?
a.isLessThan(b)
I.e. you can overload '+' to do bad things. Yes, you can, and
as I replied upthread that can be done because there's no way
to prevent that while having operator overloading at all.
But that is not justification for allowing such disasters for
the comparison operators. I.e. one weakness is
On 30/09/2016 2:18 AM, Jacob Carlborg wrote:
On 2016-09-29 14:57, rikki cattermole wrote:
Me and Cauterite were toying with the idea of AST macros but in a
completely new form a while ago.
Below is the usage of it.
Something you'll notice about it is that it could turn the asm block
into a
On Thursday, 29 September 2016 at 12:54:54 UTC, Jacob Carlborg
wrote:
BTW, there's a CTFE parser generator for D around somewhere.
And that will handle all that the DMD parser does? I don't
think so.
I agree with this entirely. Lest you have an entire D compiler
implemented in CTFE
On 2016-09-29 14:57, rikki cattermole wrote:
Me and Cauterite were toying with the idea of AST macros but in a
completely new form a while ago.
Below is the usage of it.
Something you'll notice about it is that it could turn the asm block
into a library solution (which is clearly what we'd
On 2016-09-29 11:31, pineapple wrote:
This is not an argument to justify adding just any feature, it's an
argument that it is idiocy to give a programmer a powerful tool, and
then impose arbitrary limitations upon how they are allowed to use it.
One of the most popular topics of discussion in
Me and Cauterite were toying with the idea of AST macros but in a
completely new form a while ago.
Below is the usage of it.
Something you'll notice about it is that it could turn the asm block
into a library solution (which is clearly what we'd want anyway). Not to
mention Linq style
On 2016-09-29 09:58, Walter Bright wrote:
I.e. you can overload '+' to do bad things. Yes, you can, and as I
replied upthread that can be done because there's no way to prevent that
while having operator overloading at all.
But that is not justification for allowing such disasters for the
On Thursday, 29 September 2016 at 12:20:42 UTC, Russel Winder
wrote:
Opinionated is not always bad. Look at Go, the developers know
that
there is no sane way of doing generics so they ban it. Also
they know
that exceptions are totally incomprehensible to all programmers
so they
ban them. Rust
On Thu, 2016-09-29 at 11:50 +, Minty Fresh via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 11:29:55 UTC, Russel Winder
> wrote:
> >
> > However, this has come up many times, and every time Walter
> > says "no, it's wrong". Whilst the C++ iostreams << may have
> > problems,
On Wed, 2016-09-28 at 21:15 -0700, Walter Bright via Digitalmars-d
wrote:
> On 9/28/2016 1:40 PM, Timon Gehr wrote:
> >
> > What's wrong with that usage?
>
> Because then something other than comparison is happening with <=, <,
> >, >= and
> there'll be nothing in the code to give the user a
On Thursday, 29 September 2016 at 11:29:55 UTC, Russel Winder
wrote:
However, this has come up many times, and every time Walter
says "no, it's wrong". Whilst the C++ iostreams << may have
problems, using this as a single point argument as to why
overloading fails in all other cases except
On Wed, 2016-09-28 at 20:30 +, pineapple via Digitalmars-d wrote:
> On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright
> wrote:
> >
> > Because there is no way to stop the former but still have
> > operator overloading.
> >
> > To reiterate, operator overloading exists in D to
On Thursday, 29 September 2016 at 07:58:26 UTC, Walter Bright
wrote:
On 9/28/2016 11:48 PM, Jacob Carlborg wrote:
If that is not allowed, why is this allowed:
I.e. you can overload '+' to do bad things. Yes, you can, and
as I replied upthread that can be done because there's no way
to
On 29.09.2016 06:15, Walter Bright wrote:
On 9/28/2016 1:40 PM, Timon Gehr wrote:
What's wrong with that usage?
Because then something other than comparison is happening with <=,
You also complained about '+'.
<, >,
= and there'll be nothing in the code to give the user a hint.
...
On 9/28/2016 11:48 PM, Jacob Carlborg wrote:
If that is not allowed, why is this allowed:
I.e. you can overload '+' to do bad things. Yes, you can, and as I replied
upthread that can be done because there's no way to prevent that while having
operator overloading at all.
But that is not
On 2016-09-28 06:02, Walter Bright wrote:
The limitations are deliberate based on the idea that comparison
operators need to be consistent and predictable, and should have a close
relationship to the mathematical meaning of the operators. Overloading
<= to mean something other than "less than
On Wednesday, September 28, 2016 21:15:32 Walter Bright via Digitalmars-d
wrote:
> Because then something other than comparison is happening with <=, <, >, >=
> and there'll be nothing in the code to give the user a hint.
[snip]
> D has many very powerful modeling abilities, but so far we've
On Thursday, 29 September 2016 at 04:39:37 UTC, Minty Fresh wrote:
This applies to operator overloads just like everything else.
They're just syntactic sugar for functions. Documenting their
behavior is just as necessary.
I disagree with this. Operators are different in that the symbols
On Thursday, 29 September 2016 at 04:15:32 UTC, Walter Bright
wrote:
On 9/28/2016 1:40 PM, Timon Gehr wrote:
What's wrong with that usage?
Because then something other than comparison is happening with
<=, <, >, >= and there'll be nothing in the code to give the
user a hint.
There's also
On 9/28/2016 1:40 PM, Timon Gehr wrote:
What's wrong with that usage?
Because then something other than comparison is happening with <=, <, >, >= and
there'll be nothing in the code to give the user a hint.
(This is NOT expression templates.)
Right, but it's an enabler of expression
On Wednesday, 28 September 2016 at 20:40:49 UTC, Timon Gehr wrote:
This is not surprising. C++ has no good options.
This is further made worse by some C++'s more inane design
decisions (ie. allowing overloading of the comma operator).
On 28.09.2016 22:16, Walter Bright wrote:
On 9/28/2016 6:58 AM, Timon Gehr wrote:
An excellent example of that is the std.regex package.
It's actually a bad example, because it is irrelevant: it is obviously
a bad
idea to implement regex using operator overloading, because the regex
operators
On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright
wrote:
To reiterate, operator overloading exists in D to support the
inclusion of arithmetic library types. Any other purpose is
discouraged, and that includes expression templates and things
like << for iostreams.
It seeds
On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright
wrote:
Because there is no way to stop the former but still have
operator overloading.
To reiterate, operator overloading exists in D to support the
inclusion of arithmetic library types. Any other purpose is
discouraged, and
On 9/28/2016 6:58 AM, Timon Gehr wrote:
An excellent example of that is the std.regex package.
It's actually a bad example, because it is irrelevant: it is obviously a bad
idea to implement regex using operator overloading, because the regex operators
have no D equivalent.
Yet this "obviously
On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright
wrote:
The use of them to create DSLs (a technique called "expression
templates" in C++) is discouraged in D, for several reasons.
The recommended way to create DSLs in D is to parse strings
using CTFE.
I don't really come from a
On 9/28/2016 2:48 AM, Matthias Bentrup wrote:
In Mathematics the comparison operators are also commonly used for semi orders,
which cannot be implemented by opCmp, because opCmp has no way to indicate that
two values are incomparable.
Interestingly the floating point types are semi ordered (due
On Wednesday, 28 September 2016 at 14:27:58 UTC, Chris Wright
wrote:
Increment, decrement, and
test for equality is sufficient mathematically, but we want
programs that
terminate in our lifetimes.
Only for BigInts you need those three. For ints decrement is not
needed. And for most other
On Wed, 28 Sep 2016 10:06:43 +, pineapple wrote:
> I think the cleanest possible solution would be to allow comparison
> operators to be overridden with opBinary and opBinaryRight, as well, but
> use opCmp and opEquals instead if they exist. I can't think of any way
> this would break existing
On Tue, 27 Sep 2016 23:05:54 -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Wednesday, September 28, 2016 03:28:50 Minty Fresh via Digitalmars-d
> wrote:
>> Lastly, if operators are intended to behave so strictly, why does this
>> not extend then to binary arithmetic operators (+, -, *, /,
On Wednesday, 28 September 2016 at 13:58:35 UTC, Timon Gehr wrote:
Assume I have two symbolic expressions a and b:
Expression a=variable("a"), b=variable("b");
Why should I be allowed to do
auto c = a + b; // symbolic value a + b
but not
auto d = a <= b; // symbolic value a <= b
The string
On 28.09.2016 06:02, Walter Bright wrote:
On 9/27/2016 6:18 PM, Minty Fresh wrote:
So, I'm just interested in other people's thoughts are on the subject,
and
whether there are any plans to allow overloading these operators
separately.
The limitations are deliberate based on the idea that
On 28.09.2016 11:48, Matthias Bentrup wrote:
On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright wrote:
The limitations are deliberate based on the idea that comparison
operators need to be consistent and predictable, and should have a
close relationship to the mathematical meaning
I'd also like to point out a generally sound design principle:
Give the programmer as much power and flexibility as possible -
but don't forget to provide tools for simplifying common use
cases, and don't forget to define sensible defaults.
It makes a lot of sense that opCmp and opEquals
On Wednesday, 28 September 2016 at 03:28:50 UTC, Minty Fresh
wrote:
Using strings and mixins does have quite a number of downsides.
The additional work required to past the DSL aside, you also
usually lose the scope in which things are declared (especially
if you wish to reference or declare
On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright
wrote:
The limitations are deliberate based on the idea that
comparison operators need to be consistent and predictable, and
should have a close relationship to the mathematical meaning of
the operators.
In Mathematics the
On 2016-09-28 03:18, Minty Fresh wrote:
Currently, D offers fine grained overloading for most of the unary and
arithmetic binary operators, but at some point a decision was made to
lump together all of the relational operators (and if necessary, the
equality operators) into a single function
On Wednesday, September 28, 2016 03:28:50 Minty Fresh via Digitalmars-d wrote:
> Lastly, if operators are intended to behave so strictly, why does
> this not extend then to binary arithmetic operators (+, -, *, /,
> %, etc.)
> They don't follow the same rules as the binary relational
> operators,
On 9/27/2016 6:18 PM, Minty Fresh wrote:
So, I'm just interested in other people's thoughts are on the subject, and
whether there are any plans to allow overloading these operators separately.
The limitations are deliberate based on the idea that comparison operators need
to be consistent and
On Wednesday, 28 September 2016 at 03:12:05 UTC, Jonathan M Davis
wrote:
On Wednesday, September 28, 2016 01:18:58 Minty Fresh via
Digitalmars-d wrote:
Basically, having them be overloaded separately is error-prone,
and it leads to folks overloading them in ways that have
nothing to do with
On Wednesday, September 28, 2016 01:18:58 Minty Fresh via Digitalmars-d wrote:
> So, I'm just interested in other people's thoughts are on the
> subject, and whether there are any plans to allow overloading
> these operators separately.
Basically, having them be overloaded separately is
91 matches
Mail list logo
