On Wednesday, 20 December 2023 at 02:56:24 UTC, Steven
Schveighoffer wrote:
Instead you are trying to reassign the `this` reference, which
is a local (and also forbidden). Think about it a second, your
`this + rhs` is going to allocate a *new* object. Then if the
assignment to the local `this`
On Monday, 18 December 2023 at 14:38:14 UTC, Ki Rill wrote:
your code just return result value,
but it should not return but save result to "this"
see example at
https://dlang.org/spec/operatoroverloading.html#index_op_assignment
I get an error, but don't understand why.
```d
auto
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
I am trying to overload `opOpAssign` for my class. The code
compiles, but it does not seem to be working.
```d
// binary operations have already been implemented for Value
// i need +=, -=, *=, /=
auto opOpAssign(string op)(Value rhs)
On Monday, 18 December 2023 at 04:49:53 UTC, novice2 wrote:
On Monday, 18 December 2023 at 03:39:16 UTC, Ki Rill wrote:
On Sunday, 17 December 2023 at 07:05:12 UTC, Adam D. Ruppe
wrote:
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
[...]
check what `op` is. pretty sure it is
On Monday, 18 December 2023 at 03:39:16 UTC, Ki Rill wrote:
On Sunday, 17 December 2023 at 07:05:12 UTC, Adam D. Ruppe
wrote:
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
[...]
check what `op` is. pretty sure it is "+" not "+=" so your
element isnt' saved anywhere. also a bit
On Sunday, 17 December 2023 at 07:05:12 UTC, Adam D. Ruppe wrote:
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
[...]
check what `op` is. pretty sure it is "+" not "+=" so your
element isnt' saved anywhere. also a bit iffy there isn't a
member here to work on
Yes, op is '+'.
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
auto opOpAssign(string op)(in ElementType rhs)
{
mixin("return this" ~ op ~ "rhs;");
}
```
check what `op` is. pretty sure it is "+" not "+=" so your
element isnt' saved anywhere. also a bit iffy there isn't a
member here to
On Sunday, 17 December 2023 at 04:15:02 UTC, Ki Rill wrote:
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
I am trying to overload `opOpAssign` for my class. The code
[...]
I forgot to mention, it is relevant to
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
I am trying to overload `opOpAssign` for my class. The code
[...]
I forgot to mention, it is relevant to
[`Value`](https://github.com/rillki/tiny-grad/blob/main/source/rk/tgrad/core/value.d) class only.
I am trying to overload `opOpAssign` for my class. The code
compiles, but it does not seem to be working.
```d
// binary operations have already been implemented for Value
// i need +=, -=, *=, /=
auto opOpAssign(string op)(Value rhs)
{
mixin("return this" ~ op ~ "rhs;");
}
auto
On Monday, 8 February 2021 at 15:56:24 UTC, Michael Brown wrote:
Hi all,
Is it possible to operator overload on enums? I'd like to do a
opCmp()
Kind regards,
Mike
You can create custom struct type with opCmp() and create enum
with that type. Example: https://run.dlang.io/is/m7DN66
Hi all,
Is it possible to operator overload on enums? I'd like to do a
opCmp()
Kind regards,
Mike
On Monday, 8 February 2021 at 15:56:24 UTC, Michael Brown wrote:
Hi all,
Is it possible to operator overload on enums? I'd like to do a
opCmp()
Kind regards,
Mike
No, it isn't. Only structs and classes can have overloaded
operators.
On 1/10/21 7:27 PM, Paul wrote:
> On Monday, 11 January 2021 at 02:37:24 UTC, Ali Çehreli wrote:
>> >> T opCast(T)() const if (is(T : Vec!(size, S2), S2)) {
>
>> The is expression can be so complicated that I used a different
>> approach below.
>
>> if (isInstanceOfVec!T &&
>>
On Monday, 11 January 2021 at 03:40:41 UTC, Paul wrote:
On Monday, 11 January 2021 at 00:48:49 UTC, Steven
Schveighoffer wrote:
I would think though, that this should work:
T opCast(T : Vec!(vecsize, S), S)()
Oh wouw, this seems to work perfectly! Awesome thanks ^^
Any Idea why
T opCast(T,
On Monday, 11 January 2021 at 00:48:49 UTC, Steven Schveighoffer
wrote:
I would think though, that this should work:
T opCast(T : Vec!(vecsize, S), S)()
Oh wouw, this seems to work perfectly! Awesome thanks ^^
Any Idea why
T opCast(T, S)() const if (is(T : Vec!(grootte, S))) {
yields the
On Monday, 11 January 2021 at 02:37:24 UTC, Ali Çehreli wrote:
>> T opCast(T)() const if (is(T : Vec!(size, S2), S2)) {
The is expression can be so complicated that I used a different
approach below.
if (isInstanceOfVec!T &&
T.init.content.length == size) {
// ADDED:
On 1/10/21 6:37 PM, Ali Çehreli wrote:
>// OBSERVATION: Should the cast below be S?
>converted.content[i] = cast(S2) content[i];
I take that back. Yes, it should be S2. (I've been off lately. :) )
Ali
On 1/10/21 5:09 PM, Paul wrote:
> I'll paste more of my file, I hope that's ok.
Not only ok but much appreciated. :)
>> T opCast(T)() const if (is(T : Vec!(size, S2), S2)) {
The is expression can be so complicated that I used a different approach
below. I left notes in capital letters
On Monday, 11 January 2021 at 00:25:36 UTC, Ali Çehreli wrote:
You don't show complete code; so, I hope I came up with
something that reflects your case.
Thank you, sadly S (S2 now) is not any specific type, sorry I'll
paste more of my file, I hope that's ok. (Sidenote, I'm not sure
it's the
On 1/10/21 7:09 PM, Paul wrote:
Is there a way to have additional template arguments in operator overloads?
The problem I'm having is mostly caused by casting a templated struct to
other templated structs. I had the following code;
T opCast(T)() const if (is(T : Vec!(vecsize, S), S)) {
T
On 1/10/21 4:09 PM, Paul wrote:
> Is there a way to have additional template arguments in operator
overloads?
I haven't tried that but the following method seems to work for you. You
don't show complete code; so, I hope I came up with something that
reflects your case.
import std;
struct
Is there a way to have additional template arguments in operator
overloads?
The problem I'm having is mostly caused by casting a templated
struct to other templated structs. I had the following code;
T opCast(T)() const if (is(T : Vec!(vecsize, S), S)) {
T converted;
static
On Saturday, 12 December 2020 at 20:25:48 UTC, Adam D. Ruppe
wrote:
On Saturday, 12 December 2020 at 18:14:31 UTC, Paul Backus
wrote:
IMO this is one of the stupider design decisions in D, but
it's unlikely it will ever be fixed.
It is useful in several other contexts though, including user
On Saturday, 12 December 2020 at 20:26:00 UTC, Dennis wrote:
If issue 19365 got fixed
eeek I thought that was fixed but apparently not :(
so yeah alias won't work for operator overloads. Does work for
other functions so good technique to know but not here.
So for op prolly go with the
On Saturday, 12 December 2020 at 18:14:31 UTC, Paul Backus wrote:
IMO this is one of the stupider design decisions in D, but it's
unlikely it will ever be fixed.
It is useful in several other contexts though, including user
overriding and private data stores for the mixin.
The easiest
On Saturday, 12 December 2020 at 18:14:31 UTC, Paul Backus wrote:
IMO this is one of the stupider design decisions in D, but it's
unlikely it will ever be fixed. The easiest workaround is to
use string mixins instead, which work the way you'd expect them
to.
If issue 19365 got fixed, it
On Saturday, 12 December 2020 at 18:14:31 UTC, Paul Backus wrote:
Functions from different mixin templates can't overload each
other. The reason for this is that, when you mix in a mixin
template, it does not *actually* add the declarations inside it
to a current scope: instead, it adds them
On Saturday, 12 December 2020 at 17:36:57 UTC, Tobias Pankrath
wrote:
I want to wrap e.g. an int and implement basic arithmetic. In
the provided example [1] I use two mixin templates to
separately implement scaling (multiplication with int/double)
and addition and subtraction with the type
I want to wrap e.g. an int and implement basic arithmetic. In the
provided example [1] I use two mixin templates to separately
implement scaling (multiplication with int/double) and addition
and subtraction with the type itself.
In the end I want to have several distinct wrappers and allow
On Friday, 11 October 2019 at 13:13:46 UTC, Dennis wrote:
On Friday, 11 October 2019 at 12:45:59 UTC, Boyan Lazov wrote:
Any ideas what I'm doing wrong?
Nothing, it's a bug.
https://issues.dlang.org/show_bug.cgi?id=19476
Alright, I see
Well, the alias workaround works, so that seems just as
On Friday, 11 October 2019 at 12:45:59 UTC, Boyan Lazov wrote:
Any ideas what I'm doing wrong?
Nothing, it's a bug.
https://issues.dlang.org/show_bug.cgi?id=19476
Hello,
I seem to have a problem when I use a template mixin and then try
to overload operators both in the mixin and in a struct from
where it's instantiated.
So the idea is that I have a few operators defined in the mixin,
then a few more in the struct, and I want to forward all
operations
On Sunday, 21 April 2019 at 18:17:00 UTC, Adam D. Ruppe wrote:
On Sunday, 21 April 2019 at 18:07:08 UTC, Ferhat Kurtulmuş
wrote:
I am writing an opencv binding and need something like: Mat m
= another_mat > 5;
D does not support that. The comparison operators are always
just true or false
On Sunday, 21 April 2019 at 18:07:08 UTC, Ferhat Kurtulmuş wrote:
I am writing an opencv binding and need something like: Mat m =
another_mat > 5;
D does not support that. The comparison operators are always just
true or false (as determined by the int opCmp or the bool
opEquals returns),
I am writing an opencv binding and need something like: Mat m =
another_mat > 5;
Docs does not cover this sitiuation:
https://dlang.org/spec/operatoroverloading.html#compare
opBinary does not support those operators, and Section
"Overloading <, <=, >, and >=" describes overloaded operators
On Fri, Mar 15, 2019 at 04:29:22PM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 03/15/2019 03:48 PM, H. S. Teoh wrote:
[...]
> > Ali's example was unfortunately deceptively formatted.
>
> My editor did that. :)
This is why I don't trust auto-formatters. ;-)
> On my work computer,
On 03/15/2019 03:48 PM, H. S. Teoh wrote:
On Fri, Mar 15, 2019 at 10:30:41PM +, eXodiquas via Digitalmars-d-learn
wrote:
On Friday, 15 March 2019 at 21:46:50 UTC, Ali Çehreli wrote:
[...]
Or use template constraints:
struct Vector {
Vector opBinary(string op)(Vector rhs)
if (op
On Fri, Mar 15, 2019 at 10:30:41PM +, eXodiquas via Digitalmars-d-learn
wrote:
> On Friday, 15 March 2019 at 21:46:50 UTC, Ali Çehreli wrote:
[...]
> > Or use template constraints:
> >
> > struct Vector {
> > Vector opBinary(string op)(Vector rhs)
> > if (op == "+") {
> > return
On Fri, Mar 15, 2019 at 09:35:12PM +, eXodiquas via Digitalmars-d-learn
wrote:
[...]
> Vector opBinary(string op)(Vector rhs)
> {
> static if (op == "+") return Vector(this.x + rhs.x, this.y + rhs.y);
> else static if (op == "-") return Vector(this.x - rhs.x, this.y -
> rhs.y);
> }
>
16.03.2019 1:30, eXodiquas пишет:
On Friday, 15 March 2019 at 21:46:50 UTC, Ali Çehreli wrote:
On 03/15/2019 02:43 PM, Sebastiaan Koppe wrote:
On Friday, 15 March 2019 at 21:35:12 UTC, eXodiquas wrote:
Is there any way to achive this behaivour with D2?
Yep. Just make the return type in the
On Friday, 15 March 2019 at 21:46:50 UTC, Ali Çehreli wrote:
On 03/15/2019 02:43 PM, Sebastiaan Koppe wrote:
On Friday, 15 March 2019 at 21:35:12 UTC, eXodiquas wrote:
Is there any way to achive this behaivour with D2?
Yep. Just make the return type in the function declaration
`auto`. You
On 03/15/2019 02:43 PM, Sebastiaan Koppe wrote:
On Friday, 15 March 2019 at 21:35:12 UTC, eXodiquas wrote:
Is there any way to achive this behaivour with D2?
Yep. Just make the return type in the function declaration `auto`. You
are then free to return a different type in each static branch.
On Friday, 15 March 2019 at 21:35:12 UTC, eXodiquas wrote:
Is there any way to achive this behaivour with D2?
Yep. Just make the return type in the function declaration
`auto`. You are then free to return a different type in each
static branch.
Hi everyone,
i'm currently working on a small physics engine and I thought it
would be a nice feature to overload the operators of my vector
struct so I don't have to make ugly function calls just to add
and "multiply" my vectors. The problem now is that overloading
the addition and
On Thursday, 14 March 2019 at 19:39:53 UTC, Alec Stewart wrote:
For < and >, would one do this?
I think you'd benefit a lot by reading
http://ddili.org/ders/d.en/operator_overloading.html (just search
for opCmp). I bet that will eliminate most of your confusion !
On Thursday, 14 March 2019 at 18:25:17 UTC, H. S. Teoh wrote:
On Thu, Mar 14, 2019 at 06:07:46PM +, Alec Stewart via
Digitalmars-d-learn wrote: [...]
bool opEquals(ref const Interval i) const {
// probably would be a bit more than just this, but
for this issue
// let's
On Thu, Mar 14, 2019 at 06:07:46PM +, Alec Stewart via Digitalmars-d-learn
wrote:
[...]
> bool opEquals(ref const Interval i) const {
> // probably would be a bit more than just this, but for this issue
> // let's just stick with this.
> return
On Thursday, 14 March 2019 at 18:07:46 UTC, Alec Stewart wrote:
// let's just stick with this.
return d_start.opEquals(other.d_start) &&
d_end.opEquals(other.d_end);
Why not just use d_start == other.d_start && d_end == other.d_end
there?
So should I both
ble using argument
types `(const(ulong), const(ulong))`, candidates are:` and it
doesn't say the candidates.
So should I bother with operator overloading here, or just make a
member function?
[1] https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm
On Wednesday, 22 August 2018 at 12:36:39 UTC, Simen Kjærås wrote:
Since both your opOpAssigns match equally, the compiler throws
up. The solution is to add some sort of restriction:
This doesn't happen apparently: the operator has a left and a
right side, even if both types define the
On Wednesday, 22 August 2018 at 13:20:01 UTC, aliak wrote:
"void opOpAssign(string op, T)(ref Tthis, const ref T x)" looks
like the wrong signature for opOpAssign.
Oh I'll put on my stupid hat now...
I realize I had copy-pasted the wrong syntax from the global
function attempt, but I swear
is not as advantageous as I
think, and I may change this design from structs to classes, or
else the code duplication would be small and never subject to
change. But now I'm just trying for the sake of learning to
find out what works or not in terms of templated operator
overloading, and whether the reason
On Wednesday, 22 August 2018 at 11:58:25 UTC, XavierAP wrote:
When I want to have the same operator overloading code in both
types however, I can't make it work:
From https://dlang.org/spec/operatoroverloading.html#binary:
"the one with the ‘better’ match is selected. It is an error for
to classes, or else the code
duplication would be small and never subject to change. But now
I'm just trying for the sake of learning to find out what works
or not in terms of templated operator overloading, and whether
the reason something doesn't work is by design and if mentioned
On Sunday, 20 August 2017 at 12:46:59 UTC, Nicholas Wilson wrote:
Did you try changing the `: "+"` constraints to `if`
constraints?
Yes. Yields the same result as this.
On Saturday, 19 August 2017 at 10:16:18 UTC, Balagopal Komarath
wrote:
Let us say I want to automatically define subtraction given
that addition and negation are defined. I tried the following
using mixin templates. If I simply mixin the template using
"mixin sub;", then it gives the error
On Saturday, 19 August 2017 at 10:16:18 UTC, Balagopal Komarath
wrote:
Let us say I want to automatically define subtraction given
that addition and negation are defined. I tried the following
using mixin templates...
I assume there is no way to do this?
Let us say I want to automatically define subtraction given that
addition and negation are defined. I tried the following using
mixin templates. If I simply mixin the template using "mixin
sub;", then it gives the error
tmpmixin.d(29): Error: incompatible types for ((a) - (b)): 'A!0'
and
On 6/19/17 8:16 AM, Martin Tschierschke wrote:
Just a thought it might be useful for cut-n-paste when porting code:
Would it be possible to define an operator overloading for '+'-Operator
for strings to work as append? (like ~).
I understand, that '~' is in general a better choice than '+', so
On Monday, 19 June 2017 at 12:22:43 UTC, ketmar wrote:
Martin Tschierschke wrote:
Just a thought it might be useful for cut-n-paste when porting
code:
Would it be possible to define an operator overloading for
'+'-Operator for strings to work as append? (like ~).
I understand
Martin Tschierschke wrote:
Just a thought it might be useful for cut-n-paste when porting code:
Would it be possible to define an operator overloading for '+'-Operator
for strings to work as append? (like ~).
I understand, that '~' is in general a better choice than '+', so this is
of more
Just a thought it might be useful for cut-n-paste when porting
code:
Would it be possible to define an operator overloading for
'+'-Operator for strings to work as append? (like ~).
I understand, that '~' is in general a better choice than '+', so
this is of more theoretical interest
On Tuesday, 13 June 2017 at 19:29:26 UTC, Gary Willoughby wrote:
Is it possible for the `result` variable in the following code
to be returned as an immutable type if it's created by adding
two immutable types?
Why do you even want that? Such plain data structure is
implicitly convertible to
On 06/14/2017 03:47 AM, Steven Schveighoffer wrote:
The fundamental difference is that const and immutable share a
characteristic that mutable doesn't -- you can't mutate the data.
(... through the reference at hand.)
const and mutable share this: The data may be mutated from elsewhere.
On 6/13/17 7:51 PM, ag0aep6g wrote:
On 06/14/2017 12:45 AM, Steven Schveighoffer wrote:
No, the fact that immutable implicitly casts to const(inout) is a
special property enabled by the knowledge that immutable data can
NEVER change, so it's OK to assume it's (at least) const for all
On 06/14/2017 12:45 AM, Steven Schveighoffer wrote:
No, the fact that immutable implicitly casts to const(inout) is a
special property enabled by the knowledge that immutable data can NEVER
change, so it's OK to assume it's (at least) const for all references.
The same cannot be true of const
On 6/13/17 5:58 PM, ag0aep6g wrote:
On 06/13/2017 10:50 PM, Steven Schveighoffer wrote:
const(inout) actually *is* a thing :)
It's a type constructor that can be implicitly cast from immutable.
This has advantages in some cases.
See (horribly written) table at the bottom if the inout function
On 06/13/2017 10:50 PM, Steven Schveighoffer wrote:
const(inout) actually *is* a thing :)
It's a type constructor that can be implicitly cast from immutable. This
has advantages in some cases.
See (horribly written) table at the bottom if the inout function section
here:
On 6/13/17 3:58 PM, ag0aep6g wrote:
On 06/13/2017 09:29 PM, Gary Willoughby wrote:
Is it possible for the `result` variable in the following code to be
returned as an immutable type if it's created by adding two immutable
types?
Qualify the return type as `inout`:
inout(Rational)
On 06/13/2017 09:29 PM, Gary Willoughby wrote:
Is it possible for the `result` variable in the following code to be
returned as an immutable type if it's created by adding two immutable
types?
Qualify the return type as `inout`:
inout(Rational) opBinary(/*...*/)(/*...*/) inout {/*...*/}
On Tuesday, 13 June 2017 at 11:36:45 UTC, Steven Schveighoffer
wrote:
Nope, const works just fine. A clue is in your return type --
it's not inout!
This should work:
public Rational opBinary(string op)(Rational rhs) const
If Rational had any indirections, then inout would be required,
and
On 6/12/17 3:36 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Mon, Jun 12, 2017 at 07:38:44PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
In the following code is there any way to make the `opBinary` method
generic to be able to accept immutable as well as a standard type? The
On 6/12/17 3:51 PM, Gary Willoughby wrote:
I don't know how H. S. Teoh managed to answer 'before' I posted but
thanks guys! :)
D programmers are *that* good.
Seriously though, for NNTP connections, timestamp is taken from the
submitter's PC.
-Steve
On Monday, 12 June 2017 at 20:10:17 UTC, H. S. Teoh wrote:
Therefore, nowadays I always recommend writing parenthesis with
type modifiers, so that the intent it unambiguous, i.e., always
write `inout(Rational)` rather than `inout Rational`, unless
you intend for `inout` to apply to the
On Mon, Jun 12, 2017 at 01:08:13PM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 06/12/2017 01:03 PM, Gary Willoughby wrote:
> > On Monday, 12 June 2017 at 19:36:52 UTC, H. S. Teoh wrote:
>
> >> public inout Rational opBinary(string op)(inout Rational rhs)
>
> > Quick question
On 06/12/2017 01:03 PM, Gary Willoughby wrote:
> On Monday, 12 June 2017 at 19:36:52 UTC, H. S. Teoh wrote:
>> public inout Rational opBinary(string op)(inout Rational rhs)
> Quick question about the signature, if I change it to (note the parens):
>
>public inout(Rational)
On Monday, 12 June 2017 at 19:36:52 UTC, H. S. Teoh wrote:
On Mon, Jun 12, 2017 at 07:38:44PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
In the following code is there any way to make the `opBinary`
method generic to be able to accept immutable as well as a
standard type? The code
On Monday, 12 June 2017 at 19:51:37 UTC, Gary Willoughby wrote:
I don't know how H. S. Teoh managed to answer 'before' I posted
but thanks guys! :)
might be a bug, happened here
http://forum.dlang.org/post/ohbr5l$2mng$1...@digitalmars.com also.
I don't know how H. S. Teoh managed to answer 'before' I posted
but thanks guys! :)
Gary Willoughby wrote:
In the following code is there any way to make the `opBinary` method
generic to be able to accept immutable as well as a standard type? The
code currently passes the unit test but I wonder if I could get rid of
the duplication to overload the operator? I'm failing
On Mon, Jun 12, 2017 at 07:38:44PM +, Gary Willoughby via
Digitalmars-d-learn wrote:
> In the following code is there any way to make the `opBinary` method
> generic to be able to accept immutable as well as a standard type? The
> code currently passes the unit test but I wonder if I could
In the following code is there any way to make the `opBinary`
method generic to be able to accept immutable as well as a
standard type? The code currently passes the unit test but I
wonder if I could get rid of the duplication to overload the
operator? I'm failing badly.
import std.stdio;
valuable). Personally, I've dealt with
functional languages enough that I've never felt that UFCS was much of an
improvement syntactically. But we have it, and anyone is free to use it or
not as they see fit.
Regardless, what I'm arguing against here is altering operator overloading
so that it work
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
And the fact that allowing free functions to overload operators
via UFCS sends us into that territory just highlights the fact
that they're a horrible idea.
- Jonathan M Davis
Do you have any examples of UFCS doing bad things?
Here's one more vote for extending UFCS to operator overloading.
Elie wrote that it's "a restriction that seems pointless and
arbitrary"... which summarizes my own thoughts rather well, too.
There are certainly concerning scenarios that can arise from
making this change, but the c
-in and user-defined types
as much as possible. Turtles all the way down...
They don't need operator overloading. They already have the
operators. Operators are supposed to be used as operators, not
functions, and if there's any need to use them as functions,
then there's something seriously wron
On Monday, 30 May 2016 at 05:54:42 UTC, Nicholas Wilson wrote:
Is it legal/possible to overload the unary * operator? Also is
it legal/possible to individually overload the comparison
operators and not return a bool?
Yes to unary * (see [1]). No to the rest. Comparisons are always
lowered to
Is it legal/possible to overload the unary * operator? Also is it
legal/possible to individually overload the comparison operators
and not return a bool?
(Before you ask no I'm not crazy, I am trying to make a library
solution to multiple address spaces for supporting OpenCL/CUDA in
D, and
anyone except where
the compiler lowers code to use them. They're for declaring overloaded
operators on user-defined types so that those types can be used with those
operators. If you're calling opBinary in your own code, you're doing it
wrong. And it would be downright silly to then add opBinary to
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
The difference is that it's impossible to do
10.opBinary!"+"(15), so if you're forced to do
foo.opBinary!"+"(bar) to get around a symbol conflict, it won't
work with built-in types.
Well, that begs the question: Why don't
On 25.05.2016 01:19, Elie Morisse wrote:
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
Afaik free-function operator overloads (but not in the context of
UFCS) were considered and turned down because D did not want to get
amidst discussions about adding Koenig lookup. UFCS does
"+"(bar) to get around a symbol conflict, it won't
> > work with built-in types.
>
> Obviously operator overloading should be limited to class and
> struct types, so that's not really relevant.
It's completely relevent, because generic code is frequently going to
opera
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
The difference is that it's impossible to do
10.opBinary!"+"(15), so if you're forced to do
foo.opBinary!"+"(bar) to get around a symbol conflict, it won't
work with built-in types.
Obviously operato
t do
with operators - particularly built-in operators.
D was designed to be much cleaner with operator overloading than C++ is. It
restricts what the definitions of the operators are so that you don't have
to define as many of them to get the basic operations (e.g. opCmp for most
of the comparison opera
On Wednesday, 25 May 2016 at 21:50:06 UTC, Jonathan M Davis wrote:
It's not an overloaded operator anymore at that point, and that
definitely fails to work for generic code, since not all
operators are overloaded operators. Free functions don't have
that problem.
Sorry to reiterate the
> If UFCS doesn't work, because there are two free functions with
> > the same name which take the same arguments, then you can
> > differentiate between them by not using UFCS and using their
> > full import paths, or you can alias them so that they don't
> &
are two free functions with
the same name which take the same arguments, then you can
differentiate between them by not using UFCS and using their
full import paths, or you can alias them so that they don't
have the same name. Neither of those would be possible with
operator overloading. I
re two free functions with the same
name which take the same arguments, then you can differentiate between them
by not using UFCS and using their full import paths, or you can alias them
so that they don't have the same name. Neither of those would be possible
with operator overloading. If overloaded
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
Afaik free-function operator overloads (but not in the context
of UFCS) were considered and turned down because D did not want
to get amidst discussions about adding Koenig lookup. UFCS does
not do Koenig lookup.
I don't get it,
1 - 100 of 273 matches
Mail list logo
