', you had a type
conversion problem, not an operator problem, you wrongly
assumed that adding two chars will result in a char, not an
int. In the hypothetically code 'a' + 'b' ~ "s" is also
"195s".
I had to go back and check. Yes, it app
"s" will
render the correct result.
Even if C# would use '~' instead of '+', you had a type
conversion problem, not an operator problem, you wrongly assumed
that adding two chars will result in a char, not an int. In the
hypothetically code 'a' + 'b' ~ "s" is also "195s".
On Saturday, 26 May 2018 at 11:04:44 UTC, Nick Treleaven wrote:
I don't think it makes sense to allow adding two characters -
the second operand should be an integer type.
So it would behave like pointer arithmetic. Sounds sound. Not for
D because of the C semantic similarity requirement but
On Friday, 25 May 2018 at 08:27:30 UTC, Dukc wrote:
If you add two characters, it interprets it as a concatenation
that results in a string with two charactes.
...
Now, if I were programming in D, this would not have happened.
Using + always means an addition.
I don't think it makes sense to
On Saturday, 26 May 2018 at 09:01:29 UTC, rumbu wrote:
Sorry, but the mistake here is the fact that you wrongly assume
C behavior in C#.
Yes it is. But that does not make differentiating concat and
addition in language desing any less worthwhile. In car crashes,
the mistake is usually made by
nd it's because they
have a fundamentally different meaning. Good work, whoever
chose that meaning!
Sorry, but the mistake here is the fact that you wrongly assume C
behavior in C#. Adding chars to an existing string will result in
a string as in the language specification. The same '
On Friday, 25 May 2018 at 23:05:51 UTC, Jonathan M Davis wrote:
Sure, it can be argued that this should be unnecessary and that
the programmer should just get it right, but it's not an
altogether uncommon bug to screw up case statements and
invadvertently fall through to the next one when you
On Friday, 25 May 2018 at 23:57:03 UTC, IntegratedDimensions
wrote:
So, you think by forcing programmers to use a break, goto, or
return at the end of a case somes errors but really what it
does it make programmers less aware of the problems. They
become less effective programmers in the long r
On Friday, May 25, 2018 23:57:03 IntegratedDimensions via Digitalmars-d
wrote:
> On Friday, 25 May 2018 at 23:05:51 UTC, Jonathan M Davis wrote:
> So, you think by forcing programmers to use a break, goto, or
> return at the end of a case somes errors but really what it does
> it make programmers
On Friday, 25 May 2018 at 23:05:51 UTC, Jonathan M Davis wrote:
On Friday, May 25, 2018 22:23:07 IntegratedDimensions via
Digitalmars-d wrote:
On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:
> On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
>> This ambiguity bug with + has been
On Friday, May 25, 2018 22:23:07 IntegratedDimensions via Digitalmars-d
wrote:
> On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:
> > On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
> >> This ambiguity bug with + has been causing well-known problems
> >> since Algol. A *really* lon
On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:
On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
This ambiguity bug with + has been causing well-known problems
since Algol. A *really* long time. Yet it gets constantly
welded into new languages.
Yeah. I could understand that
On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
This ambiguity bug with + has been causing well-known problems
since Algol. A *really* long time. Yet it gets constantly
welded into new languages.
Yeah. I could understand that choice for a language that tries to
be simple for be
On 5/25/2018 1:27 AM, Dukc wrote:
So, ~ may be a bit confusing for newcomers, but there is a solid reason why it's
used instead of +, and it's because they have a fundamentally different meaning.
Good work, whoever chose that meaning!
This ambiguity bug with + has been causing well-known probl
I was programming in C# and wanted to format an int in
hexadecimal. It may be that I should have used some library
function for that, but I decided to roll my own function for that
anyway, in my general utility class:
public static string FormatHexadecimal(int what)
{ if (what == 0) return "
On Monday, 26 February 2018 at 21:07:52 UTC, Meta wrote:
This is possible in the language today using the implicit class
construction feature of runtime variadic arrays:
class VArray
{
Variant[] va;
this(T...)(T ts) { foreach(t; ts) { va ~= Variant(t); } }
}
void test(VArray ta...)
.
On Monday, 26 February 2018 at 21:36:49 UTC, ketmar wrote:
aliak wrote:
It makes libraries *much* more intuitive and expressive (C++
just got it wrong by choosing the wrong default). If you allow
library authors to opt in instead of opt out then it becomes a
conscious decision for one.
libr
On Monday, 26 February 2018 at 19:32:44 UTC, ketmar wrote:
WebFreak001 wrote:
Now before you would have only been able to do this:
---
Nullable!Foo a;
foo(a, Nullable!int(5));
---
but now you should also be able to do:
---
Nullable!Foo x = null;
Nullable!Foo y = 5;
foo(null, 5);
please no
On Monday, 26 February 2018 at 23:33:48 UTC, H. S. Teoh wrote:
Not really a big deal (and auto kind of ruins it) but it would
make stuff consistent between user types and built in ones.
Not sure what you mean here. In a user type, if opBinary!"/"
returns an int, then you still have the same p
On Tuesday, 27 February 2018 at 13:36:30 UTC, ketmar wrote:
aliak wrote:
On Monday, 26 February 2018 at 21:34:21 UTC, ketmar wrote:
aliak wrote:
And if that's also a no no, how about char -> int. Or int ->
float? Is ok?
no, it is not ok. it was a mistake. it is now too late to fix
it, but
aliak wrote:
On Monday, 26 February 2018 at 21:34:21 UTC, ketmar wrote:
aliak wrote:
And if that's also a no no, how about char -> int. Or int -> float? Is
ok?
no, it is not ok. it was a mistake. it is now too late to fix it, but we
can avoid doing more of the same kind.
Oops, yeah, ok,
On Monday, 26 February 2018 at 19:25:06 UTC, WebFreak001 wrote:
hi, I had an idea from using some C# which I think would be
really cool in D. Basically allow modifying implicit
construction of a type. Right now we only have struct
opAssign/constructor implicit conversion, but this addition
wou
On Monday, 26 February 2018 at 21:36:49 UTC, ketmar wrote:
aliak wrote:
It makes libraries *much* more intuitive and expressive (C++
just got it wrong by choosing the wrong default). If you allow
library authors to opt in instead of opt out then it becomes a
conscious decision for one.
libr
On Monday, 26 February 2018 at 21:34:21 UTC, ketmar wrote:
aliak wrote:
And if that's also a no no, how about char -> int. Or int ->
float? Is ok?
no, it is not ok. it was a mistake. it is now too late to fix
it, but we can avoid doing more of the same kind.
Oops, yeah, ok, D char ... cha
On Mon, Feb 26, 2018 at 09:45:03PM +, TheFlyingFiddle via Digitalmars-d
wrote:
> On Monday, 26 February 2018 at 21:30:09 UTC, aliak wrote:
> > On Monday, 26 February 2018 at 19:32:44 UTC, ketmar wrote:
> > > WebFreak001 wrote:
> > And if that's also a no no, how about char -> int. Or int -> fl
On Monday, 26 February 2018 at 21:30:09 UTC, aliak wrote:
On Monday, 26 February 2018 at 19:32:44 UTC, ketmar wrote:
WebFreak001 wrote:
And if that's also a no no, how about char -> int. Or int ->
float? Is ok?
Maybe there're some valid arguments, to disallow it
*completely* though?
Cheers
aliak wrote:
It makes libraries *much* more intuitive and expressive (C++ just got it
wrong by choosing the wrong default). If you allow library authors to opt
in instead of opt out then it becomes a conscious decision for one.
library authors can create overloads for various argument types.
On Monday, 26 February 2018 at 19:32:44 UTC, ketmar wrote:
WebFreak001 wrote:
Now before you would have only been able to do this:
---
Nullable!Foo a;
foo(a, Nullable!int(5));
---
but now you should also be able to do:
---
Nullable!Foo x = null;
Nullable!Foo y = 5;
foo(null, 5);
please no
aliak wrote:
And if that's also a no no, how about char -> int. Or int -> float? Is ok?
no, it is not ok. it was a mistake. it is now too late to fix it, but we
can avoid doing more of the same kind.
On Monday, 26 February 2018 at 19:25:06 UTC, WebFreak001 wrote:
Now this would be really useful for Variant:
---
struct Variant {
this(U)(U value) @implicit { ... }
}
void bar(Variant x, Variant y) {}
Variant[] myObjects = [1, 2, "abc", new Node()];
Variant a = 4;
bar(4, "asdf");
---
Thi
WebFreak001 wrote:
Now before you would have only been able to do this:
---
Nullable!Foo a;
foo(a, Nullable!int(5));
---
but now you should also be able to do:
---
Nullable!Foo x = null;
Nullable!Foo y = 5;
foo(null, 5);
please no. such unobvious type conversions goes out of control really
hi, I had an idea from using some C# which I think would be
really cool in D. Basically allow modifying implicit construction
of a type. Right now we only have struct opAssign/constructor
implicit conversion, but this addition would also add it to
classes and make it even more convenient.
Cha
On 7/22/2017 6:03 PM, Ali Çehreli wrote:
Are the following floating operators gone?
!> !< !>= !<= <> !<> <>= !<>=
They still appear at least on the following pages:
http://dlang.org/spec/lex.html#tokens
https://wiki.dlang.org/Operator_precedence
Thanks to Andrew Edwards's warning an
Are the following floating operators gone?
!> !< !>= !<= <> !<> <>= !<>=
They still appear at least on the following pages:
http://dlang.org/spec/lex.html#tokens
https://wiki.dlang.org/Operator_precedence
Thanks to Andrew Edwards's warning and unless someone objects, I'm
removing them
On Tuesday, 10 May 2016 at 12:49:28 UTC, Steven Schveighoffer
wrote:
BTW, has anyone proposed a replacement like this?
auto ref comma(T...)(auto ref T t) if(T.length > 1)
{
return t[$-1];
}
That won't work with void expressions.
Here's a version which does:
https://github.com/CyberShadow/
On Wednesday, 18 January 2017 at 10:49:43 UTC, Nordlöw wrote:
Is there a way around this problem?
I had the same problem with opSliceAssign, opIndexAssign lately.
On Wednesday, 18 January 2017 at 10:49:43 UTC, Nordlöw wrote:
https://github.com/nordlow/gmp-d/blob/master/src/gmp.d#L1835
Should be
https://github.com/nordlow/gmp-d/blob/master/src/gmp.d#L1853
BLEM!!!: this case cannot be implemented
// in operator overloads because
// __traits(isRef, this) is incorrectly always true
// safe @nogc and no-RC lazy evaluation is possible
return MpZAddExpr!(MpZ, MpZ)(move(a), move(b));
}
else static if (!isR
a const object
object
const MyTable m2;
5 in m2; // Error: rvalue of in expression must be an
associative array, not const(MyTable)
A super-cryptic error message. First of all, "in expressions"
are not limited to associative arrays. Second, the error makes
me think I didn't i
'const(MyTable)'
You might want to add a comment there, and/or open an
enhancement request at: https://issues.dlang.org/
This is true. But currently error messages for overloaded
operator is useless in general, not just for 'in'.
Please have a look at this PR:
https://github.com/dlang/dmd/pull/6140
However, the error message printed with this PR isn't
particularly helpful either:
Error: incompatible types for ((5) in (m2)): 'int' and
'const(MyTable)'
You might want to add a comment there, and/or open an enhancement
r
r: rvalue of in expression must be an
associative array, not const(MyTable)
A super-cryptic error message. First of all, "in expressions" are
not limited to associative arrays. Second, the error makes me
think I didn't implement the operator -- but I did.
Instead, supposed I had a
On 9/25/16 9:48 AM, Jonathan M Davis via Digitalmars-d wrote:
On Sunday, September 25, 2016 13:10:42 ZombineDev via Digitalmars-d wrote:
D's built-in dynamic arrays are hidden from you and you only get
to interact with them by referring to their elements by using
slices.
That's a common miscon
On 9/25/2016 6:45 AM, Andrei Alexandrescu wrote:
Yah, it comes as a surprise to many that static arrays are more akin to structs
than to arrays. They really are records that happen to have several elements of
the same type. Providing indexing for them is a convenience that somewhat adds
to the co
On Sunday, 25 September 2016 at 15:25:38 UTC, Jonathan M Davis
wrote:
So, if they want their code to work with anyone else's code
they pretty much need to use their own set of range primitives
that do not conflict with the standard ones rather than trying
to redefine the standard ones. And if t
On Sunday, September 25, 2016 16:50:04 Andrei Alexandrescu via Digitalmars-d
wrote:
> It seems you want to define ranges with similar syntax but subtle
> semantic differences, e.g. r.front and r[0] to mean different things.
> The entire Phobos is designed under the assumptions that ranges work a
>
On 9/25/16 4:05 PM, pineapple wrote:
On Sunday, 25 September 2016 at 13:57:04 UTC, Jonathan M Davis wrote:
The way it works now is how it's always worked with dynamic arrays and
ranges in D. If you're trying do anything else, you're just going to
run into problems in the long run - particularly
On Sunday, 25 September 2016 at 13:57:04 UTC, Jonathan M Davis
wrote:
The way it works now is how it's always worked with dynamic
arrays and ranges in D. If you're trying do anything else,
you're just going to run into problems in the long run -
particularly when interacting with code written b
On Sunday, 25 September 2016 at 13:45:01 UTC, Andrei Alexandrescu
wrote:
Ranges don't need necessarily an associated Iterable. This is
the case in other languages, too; Lisp/Scheme/Haskell/etc lists
are iterables and at the same time their own iterators. But
indeed std.container is designed to
On Sunday, September 25, 2016 15:45:01 Andrei Alexandrescu via Digitalmars-d
wrote:
> Ranges don't need necessarily an associated Iterable. This is the case
> in other languages, too; Lisp/Scheme/Haskell/etc lists are iterables and
> at the same time their own iterators. But indeed std.container i
On Sunday, September 25, 2016 13:40:14 pineapple via Digitalmars-d wrote:
> On Sunday, 25 September 2016 at 11:48:38 UTC, Jonathan M Davis
>
> wrote:
> > It's because ranges are effectively a sliding window over
> > whatever they're iterating over.
>
> I think this is the difference in perception -
On Sunday, September 25, 2016 13:10:42 ZombineDev via Digitalmars-d wrote:
> D's built-in dynamic arrays are hidden from you and you only get
> to interact with them by referring to their elements by using
> slices.
That's a common misconception propagated by Steven's otherwise excellent
article.
On 9/25/16 12:58 PM, pineapple wrote:
On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis wrote:
Considering that a random access range is essentially an abstraction
for a dynamic array and that ranges were designed with that in mind, I
don't know how you can argue that dynamic arrays
On Sunday, 25 September 2016 at 11:48:38 UTC, Jonathan M Davis
wrote:
It's because ranges are effectively a sliding window over
whatever they're iterating over.
I think this is the difference in perception - ranges do not
_have_ to be sliding windows, they can just as well be windows
that don
On Sunday, 25 September 2016 at 13:10:42 UTC, ZombineDev wrote:
But which opIndex and which length? Those of the container, or
those of the range? It doesn't make any sense to expect
container[].takeExactly(7).length to be different than 7. If
range.length returns the length of the container th
On Sunday, 25 September 2016 at 10:58:24 UTC, pineapple wrote:
It gets under my skin that length and opIndex and opSlice
produce different results in phobos' ranges depending on one's
current position in the range. This doesn't make sense to me,
and the only reason I can conceive of it having
On Sunday, September 25, 2016 10:58:24 pineapple via Digitalmars-d wrote:
> On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis
>
> wrote:
> > Considering that a random access range is essentially an
> > abstraction for a dynamic array and that ranges were designed
> > with that in mind,
On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis
wrote:
Considering that a random access range is essentially an
abstraction for a dynamic array and that ranges were designed
with that in mind, I don't know how you can argue that dynamic
arrays shouldn't be treated as ranges.
Th
On Sunday, September 25, 2016 00:36:58 pineapple via Digitalmars-d wrote:
> On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei
>
> Alexandrescu wrote:
> > On 9/22/16 6:38 AM, pineapple wrote:
> >> The greatest offender I've found is how in phobos, arrays do
> >> not behave
> >> as ranges withou
On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei
Alexandrescu wrote:
On 9/22/16 6:38 AM, pineapple wrote:
The greatest offender I've found is how in phobos, arrays do
not behave
as ranges without importing the module defining their range
operations.
Would make sense to move those few pr
On Wednesday, 21 September 2016 at 21:14:15 UTC, H. S. Teoh wrote:
The problem here is that generic_code.d doesn't (and
shouldn't!) import
usertype.d, so usertype.opBinary is not visible in
generic_code.d. So
when algorithm() tries to look up the '+' operator in `t + u`
On Thursday, 22 September 2016 at 14:33:36 UTC, Andrei
Alexandrescu wrote:
On 9/22/16 10:20 AM, Jonathan M Davis via Digitalmars-d wrote:
The main problem with moving them there is auto-decoding.
front and popFront
for strings require std.utf in order to do their thing.
Druntime has it's own
-defined types.
And it widens the scope for name-conflicts immensely!
...
Operator overloading makes sense for a small minority of types and D has
plenty of mechanisms to deal with name conflicts: overload sets,
template constraints, private aliases, FQNs.
I do not see a case where UFCS overl
On Friday, September 23, 2016 13:47:06 Sai via Digitalmars-d wrote:
> > The greatest offender I've found is how in phobos, arrays do
> > not behave as ranges without importing the module defining
> > their range operations.
>
> Could you please tell me what module is it? is it std.array?
It was, b
The greatest offender I've found is how in phobos, arrays do
not behave as ranges without importing the module defining
their range operations.
Could you please tell me what module is it? is it std.array?
On Friday, 23 September 2016 at 08:50:56 UTC, Timon Gehr wrote:
FQN disables UFCS. Nothing specific to operators here.
There is no reason why there should be any difference between a
+ b and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should
work too.
Currently this is tricky to implement
t overload), but FQN's are not an option
when the call is made from generic code.
And in the case of operator overloads, FQN makes no sense at all, since it
wouldn't be using the operator anymore.
- Jonathan M Davis
FQN disables UFCS. Nothing specific to operators here.
There is no rea
On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot
wrote:
So it seems to be essential point. But because we already have
the same problem with UFCS, I don't see why we should prohibit
external overloading of operator, it is just inequality (in
political sense) for operators :)
On Thu, Sep 22, 2016 at 07:20:49AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, September 22, 2016 08:51:59 Andrei Alexandrescu via
> Digitalmars-d
> wrote:
> > On 9/22/16 6:38 AM, pineapple wrote:
> > > The greatest offender I've found is how in phobos, arrays do not
> > > be
On 9/22/16 10:20 AM, Jonathan M Davis via Digitalmars-d wrote:
The main problem with moving them there is auto-decoding. front and popFront
for strings require std.utf in order to do their thing.
Yah, that's a little hurdle. -- Andrei
On Thursday, September 22, 2016 08:51:59 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/22/16 6:38 AM, pineapple wrote:
> > The greatest offender I've found is how in phobos, arrays do not behave
> > as ranges without importing the module defining their range operations.
>
> Would make sense
On 9/22/16 6:38 AM, pineapple wrote:
The greatest offender I've found is how in phobos, arrays do not behave
as ranges without importing the module defining their range operations.
Would make sense to move those few primitives to object.d. I've been
thinking of that a long time ago but back th
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
There is no technical reason that would make the implementation
of this feature difficult, if that is your question.
Basically, the rationale is: external operators cannot be used
in generic code that does not import the module
On Thursday, 22 September 2016 at 08:58:54 UTC, HaraldZealot
wrote:
So let's vote for the following sentence:
"It would be good to have an operator overloading even without
support in generic function"
Yes
On Thursday, 22 September 2016 at 08:53:26 UTC, HaraldZealot
wrote:
OK, it seems to me it's time to investigate a community opinion.
So let's vote for the following sentence:
"It would be good to have an operator overloading even without
support in generic function"
On Thursday, 22 September 2016 at 07:14:52 UTC, H. S. Teoh wrote:
It's not so simple. The UFCS operator overload could be
declared in a different module from the type itself. Then
there is no guarantee that it will be found. Multiple calls to
the same template function with the
when the call is made from generic code.
And in the case of operator overloads, FQN makes no sense at all, since it
wouldn't be using the operator anymore.
- Jonathan M Davis
ype" which include all visible at the moment of call function and
> templates for this type.
It's not so simple. The UFCS operator overload could be declared in a
different module from the type itself. Then there is no guarantee that
it will be found. Multiple calls to the same template func
On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot
wrote:
And problem with generic code solve independently for all UFCS
functions including operators.
Unfortunately I don't know compiler and all related stuff
internally (time to change this ;) ), but it seems to me there is
a way
On Wednesday, 21 September 2016 at 21:14:15 UTC, H. S. Teoh wrote:
Thank you both, I see now.
So it seems to be essential point. But because we already have
the same problem with UFCS, I don't see why we should prohibit
external overloading of operator, it is just inequality (in
poli
UserType u1, u2;
auto r = u1 + u2; // OK
auto s = algorithm(u1, u2); // NO GOOD
}
The problem here is that generic_code.d doesn't (and shouldn't!) import
usertype.d, so usertype.opBinary is not visible in generic_code.d. So
when algorithm() tri
On 21.09.2016 22:53, HaraldZealot wrote:
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
Basically, the rationale is: external operators cannot be used in
generic code that does not import the module defining the operators.
Could you give some elaborate example, for now I c
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
Basically, the rationale is: external operators cannot be used
in generic code that does not import the module defining the
operators.
Could you give some elaborate example, for now I can't imagine
what your mean.
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
Basically, the rationale is: external operators cannot be used
in generic code that does not import the module defining the
operators.
So why not have the struct/class explicitly import external
operators? You can do this cu
On 21.09.2016 21:01, Timon Gehr wrote:
On 21.09.2016 19:57, HaraldZealot wrote:
So if someone has real rationale not to have operator overloading as
external function I'm curios to arguments.
[1] http://dlang.org/rationale.html
There is no technical reason that would mak
On 21.09.2016 19:57, HaraldZealot wrote:
So if someone has real rationale not to have operator overloading as
external function I'm curios to arguments.
[1] http://dlang.org/rationale.html
There is no technical reason that would make the implementation of this
feature difficult, if
On Wednesday, 21 September 2016 at 17:57:17 UTC, HaraldZealot
wrote:
In current D, overloading operator like "+" with external
function is prohibited. There is the rationale [1] (see second
paragraph).
[...]
I am completely agree. We should support external operator
overloading f
In current D, overloading operator like "+" with external
function is prohibited. There is the rationale [1] (see second
paragraph).
BUT this rationale is totally UNCONVINCING. I can say that resume
of rationale is: "it is impossible because it brakes some C++
pattern
> > disallowing taking the result of the comma operator. Yes there is
> > > potential breakage (via typeof as Timon noted) but it's likely to
> > > be minimal. Once we have that in place we have more options. Thx!
> > > -- Andrei
> >
> > Just a quic
On 6/10/16 1:02 PM, Mathias Lang wrote:
On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu wrote:
Before we get lost in the discussions, let's act on this by
disallowing taking the result of the comma operator. Yes there is
potential breakage (via typeof as Timon noted) but
On Thursday, 12 May 2016 at 10:29:36 UTC, Andrei Alexandrescu
wrote:
Before we get lost in the discussions, let's act on this by
disallowing taking the result of the comma operator. Yes there
is potential breakage (via typeof as Timon noted) but it's
likely to be minimal. Once we ha
uld always cause an error, iff
the result of the comma operator gets used.
int x,y;
auto f() {return (x=4,y);}
...
auto z = f();
static if (!is(typeof(z) == int)
voteForTrump();
;-)
In practice, this is more plausible with function overloading - i.e.
z.overload() calling a different functi
ult of the comma operator gets used.
int x,y;
auto f() {return (x=4,y);}
...
auto z = f();
static if (!is(typeof(z) == int)
voteForTrump();
;-)
In practice, this is more plausible with function overloading -
i.e. z.overload() calling a different function. If the comma
operator returns void, t
On 5/11/16 1:10 PM, Kagamin wrote:
On Wednesday, 11 May 2016 at 16:46:48 UTC, Nick Treleaven wrote:
In places where the comma operator does help, use a
comma(expr,result) template function, implemented here:
http://forum.dlang.org/post/ngslcl$otg$1...@digitalmars.com
May not always work
On 5/11/16 7:46 PM, Nick Treleaven wrote:
In places where the comma operator does help, use a comma(expr,result)
template function
Better yet instead of
e1, e2, e3
type
{ e1; e2; return e3; }()
Andrei
Before we get lost in the discussions, let's act on this by disallowing
taking the result of the comma operator. Yes there is potential breakage
(via typeof as Timon noted) but it's likely to be minimal. Once we have
that in place we have more options. Thx! -- Andrei
On Wednesday, 11 May 2016 at 18:37:15 UTC, Gopan wrote:
On Wednesday, 11 May 2016 at 17:15:29 UTC, Kagamin wrote:
https://dpaste.dzfl.pl/46f24c3def62
It gave compilation error because, one of the parameters of the
comma() template in your code is void. Currently, does D
support void as a ty
int x;
while( scanf("%d", &x), x!= 0) // until user input 0.
{
//do something with x
}
Does anybody think that this is a useful case of comma operator?
I think it's not a safe way to write code. The only time I use
comma in C (outside for loops) is when I write some c
never
silently change the meaning of code.
I'm trying to think of a case where changing a single value into a tuple
with 2 (or more) values would silently change the behavior, but I can't
think of any. Seems to me it would always cause an error, iff the result
of the comma operator gets used.
11 May 2016 at 16:44:43 UTC, H. S. Teoh wrote:
>>> >That's what I've been saying, it should be treated as a >special case
>>> in the syntax of for-loops, but not as an >operator in general.
>>> >
>>>
>>> Please no special cases.
>
1 - 100 of 1773 matches
Mail list logo
