On 11/14/18 4:32 PM, Neia Neutuladh wrote:
On Wed, 14 Nov 2018 13:40:46 -0500, Steven Schveighoffer wrote:
You don't think this is confusing?
enum A : int {
val
}
A a;
foo(a); // error: be more specific
int x = a;
foo(x); // Sure
I find this confusing:
void foo(int i) {}
On Wed, 14 Nov 2018 13:40:46 -0500, Steven Schveighoffer wrote:
> You don't think this is confusing?
>
> enum A : int {
> val
> }
>
> A a;
> foo(a); // error: be more specific
> int x = a;
> foo(x); // Sure
I find this confusing:
void foo(int i) {}
void foo(ubyte b) {}
enum A
On Wednesday, 14 November 2018 at 02:45:38 UTC, Walter Bright
wrote:
On 11/13/2018 3:29 PM, Rubn wrote:
> enum A : int { a = 127 }
`a` is a manifest constant of type `A` with a value of `127`.
Remember that `A` is not an `int`. It is implicitly convertible
to an integer type that its value
On Wed, Nov 14, 2018 at 06:59:30PM +, Carl Sturtivant via
Digitalmars-d-announce wrote:
> On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote:
> > *sigh* Well, I guess that's the core issue right there. A lot of us
> > would strongly disagree with the idea that bool is an
On Wednesday, 14 November 2018 at 18:11:59 UTC, Neia Neutuladh
wrote:
On Tue, 13 Nov 2018 20:27:05 -0800, Walter Bright wrote:
There have been various attempts over the years to "fix"
various things in the D matching system by adding "just one
more" match level.
I kind of feel like, if
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis
wrote:
*sigh* Well, I guess that's the core issue right there. A lot
of us would strongly disagree with the idea that bool is an
integral type and consider code that treats it as such as
inviting bugs. We _want_ bool to be
On 11/14/18 1:11 PM, Neia Neutuladh wrote:
On Tue, 13 Nov 2018 20:27:05 -0800, Walter Bright wrote:
There have been various attempts over the years to "fix" various things
in the D matching system by adding "just one more" match level.
I kind of feel like, if something would be confusing like
On Tue, 13 Nov 2018 20:27:05 -0800, Walter Bright wrote:
> There have been various attempts over the years to "fix" various things
> in the D matching system by adding "just one more" match level.
I kind of feel like, if something would be confusing like this, maybe the
compiler shouldn't be
On Wed, 14 Nov 2018 12:09:33 +0100, Jacob Carlborg wrote:
> What is ": int" doing, only specifying the size?
It specifies the type to match for overloading when the compiler isn't
required by the language to constant-fold the value.
On 2018-11-14 03:45, Walter Bright wrote:
On 11/13/2018 3:29 PM, Rubn wrote:
enum : int { a = 127 }
To reiterate, this does not create an anonymous enum type. 'a' is typed
as 'int'. Technically,
`a` is a manifest constant of type `int` with a value of `127`.
> enum A : int { a = 127 }
`a`
On 11/13/2018 8:37 PM, Isaac S. wrote:
It probably depends on where someone is from (asinine isn't considered a big
insult where I live [rural US]).
Regardless of that, I will admit I did overstep (especially in calling Walter
ignorant) and so I do apologize to Walter (I'm sorry that sounds
On 11/13/2018 8:49 PM, Jonathan M Davis wrote:
Not AFAIK, but calling someone or something extremely stupid or foolish is
almost always a terrible idea in a professional discussion (or pretty much
any discussion that you want to be civil) - especially if it can be
interpreted as calling the
On Wednesday, 14 November 2018 at 06:56:12 UTC, aliak wrote:
On Tuesday, 13 November 2018 at 09:17:51 UTC, Walter Bright
wrote:
[...]
Ok, thanks!
[...]
Bummer. At least if this enum : int case is fixed that doesn't
seem like it's hard to work out in my head at least - but I
guess I'm
On Tuesday, 13 November 2018 at 09:17:51 UTC, Walter Bright wrote:
On 11/13/2018 12:23 AM, aliak wrote:
Doesn't the above miss a step, and wouldn't it be:
1) A.a =>
2) A.a =>
So basically for the f(short) path you have 3 steps instead of
2 for the f(int) path.
So does it matter how
On Wednesday, 14 November 2018 at 04:37:38 UTC, Isaac S. wrote:
On Wednesday, 14 November 2018 at 04:27:29 UTC, Nicholas Wilson
wrote:
asinine, adjective: extremely stupid or foolish. Is there some
additional connotation I am missing on this living
(comparatively) in the middle of nowhere?
On Tuesday, November 13, 2018 9:27:29 PM MST Nicholas Wilson via
Digitalmars-d-announce wrote:
> On Wednesday, 14 November 2018 at 04:24:20 UTC, Jonathan M Davis
>
> wrote:
> > Given how strong the negative response is to this and how
> > incomprenhensible a number of us find the reasoning behind
On Wednesday, 14 November 2018 at 04:33:23 UTC, Isaac S. wrote:
On Wednesday, 14 November 2018 at 04:27:05 UTC, Walter Bright
wrote:
There have been various attempts over the years to "fix"
various things in the D matching system by adding "just one
more" match level. I've rejected all of
On Wednesday, 14 November 2018 at 04:27:29 UTC, Nicholas Wilson
wrote:
asinine, adjective: extremely stupid or foolish. Is there some
additional connotation I am missing on this living
(comparatively) in the middle of nowhere? (Genuine question.)
It probably depends on where someone is from
On Wednesday, 14 November 2018 at 04:27:05 UTC, Walter Bright
wrote:
There have been various attempts over the years to "fix"
various things in the D matching system by adding "just one
more" match level. I've rejected all of them, because things
that look simple and obvious with trivial
On Wednesday, 14 November 2018 at 04:24:20 UTC, Jonathan M Davis
wrote:
Given how strong the negative response is to this and how
incomprenhensible a number of us find the reasoning behind how
bool functions in some scenarios, Walter probably does need to
sit back and think about this, but
On 11/13/2018 7:12 PM, Isaac S. wrote:
why should an enum
not convert to its declared type, rather than blindly using its literal value.
Just using the literal value discards the secondary-type information the
programmer had given it.
D has the following match levels:
1. exact
2. conversion
On Tuesday, November 13, 2018 8:47:01 PM MST Nicholas Wilson via
Digitalmars-d-announce wrote:
> On Wednesday, 14 November 2018 at 03:02:48 UTC, Walter Bright
>
> wrote:
> > On 11/13/2018 3:50 PM, Isaac S. wrote:
> >> is asinine and ignorant.
> >
> > Some friendly advice - nobody is going to pay
On Wednesday, 14 November 2018 at 03:02:48 UTC, Walter Bright
wrote:
On 11/13/2018 3:50 PM, Isaac S. wrote:
is asinine and ignorant.
Some friendly advice - nobody is going to pay serious attention
to articles that sum up with such unprofessional statements.
Continuing the practice will just
On Wednesday, 14 November 2018 at 03:02:48 UTC, Walter Bright
wrote:
On 11/13/2018 3:50 PM, Isaac S. wrote:
is asinine and ignorant.
Some friendly advice - nobody is going to pay serious attention
to articles that sum up with such unprofessional statements.
Continuing the practice will just
On 11/13/2018 3:50 PM, Isaac S. wrote:
is asinine and ignorant.
Some friendly advice - nobody is going to pay serious attention to articles that
sum up with such unprofessional statements. Continuing the practice will just
result in the moderators removing them.
On Wednesday, 14 November 2018 at 02:45:38 UTC, Walter Bright
wrote:
In your articles, it is crucial to understand the difference
between a manifest constant of type `int` and one of type `A`.
Still doesn't change the fact that a typed enum should convert to
its own type first (rather than
On 11/13/2018 3:29 PM, Rubn wrote:
enum : int { a = 127 }
To reiterate, this does not create an anonymous enum type. 'a' is typed as
'int'. Technically,
`a` is a manifest constant of type `int` with a value of `127`.
> enum A : int { a = 127 }
`a` is a manifest constant of type `A` with a
On Wed, 14 Nov 2018 00:43:54 +, Rubn wrote:
> I wonder what these examples are? What did C++ do instead, cause
> something tells me it didn't do what D is doing. An enum in C++ doesn't
> call different function overloads based on the constant value.
Long long and unsigned long long give an
On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
One could have be treated as
"better than" , and
it sounds like a good idea, but even C++, not known for
simplicity, tried that and had to abandon it as nobody could
figure it out once the code examples got beyond trivial
On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
int f(short s) { return 1; }
int f(int i) { return 2; }
enum : int { a = 0 }
enum A : int { a = 0 }
pragma (msg, f(a)); // calls f(int)
pragma (msg, f(A.a)); // calls f(short)
*snip*
So f(short) is selected, because the
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis
wrote:
*sigh* Well, I guess that's the core issue right there. A lot
of us would strongly disagree with the idea that bool is an
integral type and consider code that treats it as such as
inviting bugs. We _want_ bool to be
On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
On 11/12/2018 12:34 PM, Neia Neutuladh wrote:
Tell me more about this "consistency".
int f(short s) { return 1; }
int f(int i) { return 2; }
enum : int { a = 0 }
enum A : int { a = 0 }
pragma (msg, f(a)); // calls f(int)
On Tue, 13 Nov 2018 17:53:27 +, 12345swordy wrote:
> Ok, now that has got to be a bug. If you explicit cast the number to an
> integer then you expect the overload function with int to be called.
>
> -Alex
...my mistake, I can't reproduce that anymore. Pretend I didn't say
anything.
On Tue, 13 Nov 2018 09:46:17 -0500, Steven Schveighoffer wrote:
> Maybe the biggest gripe here is that enums don't prefer their base types
> over what their base types convert to. In the developer's mind, the
> conversion is:
>
> A => int => (via VRP) short
>
> which seems more complex than just
On Tuesday, 13 November 2018 at 17:50:20 UTC, Neia Neutuladh
wrote:
On Tue, 13 Nov 2018 09:46:17 -0500, Steven Schveighoffer wrote:
Maybe the biggest gripe here is that enums don't prefer their
base types over what their base types convert to. In the
developer's mind, the conversion is:
A =>
On 11/13/18 11:26 AM, Chris M. wrote:
On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from integer
and character literals to bool, has been rejected, primarily on the
grounds that it is factually incorrect in treating
On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from
integer and character literals to bool, has been rejected,
primarily on the grounds that it is factually incorrect in
treating bool as a type distinct from other
On Tuesday, 13 November 2018 at 16:26:55 UTC, Chris M. wrote:
On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
[...]
I was going to write something up about how you can't do
arithmetic on bool types therefore they aren't integral, but I
tested and realized D allows this (i.e.
On 11/12/18 4:38 PM, Walter Bright wrote:
On 11/12/2018 8:28 AM, 12345swordy wrote:
The issue that I see is unintended implicit conversation when passing
values to functions that have both int and bool overloads.
The exact same thing happens when there are both int and short overloads.
The
On 11/13/2018 12:23 AM, aliak wrote:
Doesn't the above miss a step, and wouldn't it be:
1) A.a =>
2) A.a =>
So basically for the f(short) path you have 3 steps instead of 2 for the f(int)
path.
So does it matter how many implicit conversions need to happen before D stops
trying? Or is
On Tuesday, 13 November 2018 at 07:13:01 UTC, NoMoreBugs wrote:
You nailed it on the head.
The only sensible course of action, therefore, is to give
programmers the option to disable implicit conversions,
completely (or if doable, more precisely).
And while you're thinking about how to do
On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
On 11/12/2018 12:34 PM, Neia Neutuladh wrote:
Tell me more about this "consistency".
int f(short s) { return 1; }
int f(int i) { return 2; }
enum : int { a = 0 }
enum A : int { a = 0 }
pragma (msg, f(a)); // calls f(int)
On Monday, 12 November 2018 at 21:38:27 UTC, Walter Bright wrote:
On 11/12/2018 8:28 AM, 12345swordy wrote:
The issue that I see is unintended implicit conversation when
passing values to functions that have both int and bool
overloads.
The exact same thing happens when there are both int
On Tue, Nov 13, 2018 at 02:12:30AM +, 12345swordy via
Digitalmars-d-announce wrote:
> On Monday, 12 November 2018 at 21:38:27 UTC, Walter Bright wrote:
[...]
> > The underlying issue is is bool a one bit integer type, or something
> > special? D defines it as a one bit integer type, fitting
On Monday, 12 November 2018 at 21:38:27 UTC, Walter Bright wrote:
On 11/12/2018 8:28 AM, 12345swordy wrote:
The issue that I see is unintended implicit conversation when
passing values to functions that have both int and bool
overloads.
The exact same thing happens when there are both int
On Tue, 13 Nov 2018 00:28:46 +, Isaac S. wrote:
> Sorry if it wasn't clear, I meant that if `enum Foo : some_int_type`
> makes it so some_int_type is preferred (because it's a more direct
> conversion) DScanner could warn anyone that just does `enum Foo`.
Sorry, I read too hastily and thought
On Tuesday, 13 November 2018 at 00:21:25 UTC, Neia Neutuladh
wrote:
On Tue, 13 Nov 2018 00:08:04 +, Isaac S. wrote:
If you really want this plaque in the language, at least make
it not affect those that gave their enum a type. If you at
least do that, someone can add it to DScanner to tell
On Tue, 13 Nov 2018 00:08:04 +, Isaac S. wrote:
> If you really want this plaque in the language, at least make it not
> affect those that gave their enum a type. If you at least do that,
> someone can add it to DScanner to tell anyone that doesn't type their
> enum to expect illogical
On Mon, 12 Nov 2018 14:07:39 -0800, Walter Bright wrote:
> => conversion>
>=> conversion>
One confusion is from value range propagation / constant folding reaching
past the static type information to yield a different result from what
static typing alone
On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
*snip*
Both f(int) and f(short) match, because implicit conversions
rank the same.
To disambiguate, f(short) is pitted against f(int) using
partial ordering rules,
which are:
Can a short be used to call f(int)? Yes.
Can
On Monday, 12 November 2018 at 21:29:20 UTC, Walter Bright wrote:
*snip*
In my college daze I was learning programming alongside
designing and building digital circuits, and later software for
FPGAs and PLDs (ABEL). The notions of True, T, 1, !0 (from C
and Asm), and +5V are all completely
On 11/12/2018 1:39 PM, 12345swordy wrote:
OK, I got to know what language you were using at the time, because I am curious
at what other oddities does it have.
I wish I could remember what it was. It was like 40 years ago :-)
On 11/12/2018 12:34 PM, Neia Neutuladh wrote:
Tell me more about this "consistency".
int f(short s) { return 1; }
int f(int i) { return 2; }
enum : int { a = 0 }
enum A : int { a = 0 }
pragma (msg, f(a)); // calls f(int)
pragma (msg, f(A.a)); // calls f(short)
I.e. it's consistent.
On 11/12/2018 11:28 AM, Adam D. Ruppe wrote:
D used to have a `bit` type, wy back in the day. It was renamed to `bool`
way back in D 0.148, released Feb 25, 2006.
D's old bit type was not a bool. It literally was a single bit, and an array of
bits was packed into an int by the compiler.
On 11/12/2018 8:28 AM, 12345swordy wrote:
The issue that I see is unintended implicit conversation when passing values to
functions that have both int and bool overloads.
The exact same thing happens when there are both int and short overloads.
The underlying issue is is bool a one bit
On Monday, 12 November 2018 at 21:29:20 UTC, Walter Bright wrote:
I once worked with software that defined true as 0 and false as
1
OK, I got to know what language you were using at the time,
because I am curious at what other oddities does it have.
-Alex
On 11/12/2018 2:05 AM, Jonathan M Davis wrote:
*sigh* Well, I guess that's the core issue right there. A lot of us would
strongly disagree with the idea that bool is an integral type and consider
code that treats it as such as inviting bugs.
In my college daze I was learning programming
On Mon, 12 Nov 2018 20:34:11 +, Neia Neutuladh wrote:
> enum : int { a = 0 }
> enum A : int { a = 0 }
> f(a); // calls the int overload f(A.a); // calls the bool overload
>
> Tell me more about this "consistency".
Filed issue 19394. (Sorry for spam.)
On Mon, 12 Nov 2018 09:45:14 +, Mike Parker wrote:
> From Example B in the DIP:
>
> ```
> int f(bool b) { return 1; }
> int f(int i) { return 2; }
>
> enum E : int {
> a = 0,
> b = 1,
> c = 2,
> }
> ```
>
> Here, f(a) and f(b) call the bool overload, while f(c) calls the int
On Mon, 12 Nov 2018 14:10:42 -0500, Steven Schveighoffer wrote:
> But it's not consistent:
And std.traits.isIntegral has not considered bools integral since its
initial creation in 2007. Both Walter and Andrei have mucked about with
that code and saw no reason to change it, even in wild and
On Monday, 12 November 2018 at 18:25:22 UTC, Bastiaan Veelo wrote:
I can’t say I have a strong opinion on this, but possibly it
would be right to have an integral “bit” type to differentiate
it from the Boolean type, just like we have a “byte” type to
differentiate it from “char”...
D used
On 11/12/18 4:45 AM, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from integer
and character literals to bool, has been rejected, primarily on the
grounds that it is factually incorrect in treating bool as a type
distinct from other integral types.
The TL;DR
On Monday, 12 November 2018 at 17:49:55 UTC, Joakim wrote:
[…]
it's quite simple: they view a bool as an integral type with
two possible values, a `bit` if you like. As such, they prefer
to fit it into the existing scheme for integral types rather
than special-casing booleans as Mike proposed.
On Monday, 12 November 2018 at 17:25:15 UTC, Johannes Loher wrote:
On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote:
Walter and Andrei take the position that this is incorrect the
wrong way to view a bool.
Unfortunately you did not include their justification for this
position
On Monday, 12 November 2018 at 17:25:15 UTC, Johannes Loher wrote:
On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote:
Walter and Andrei take the position that this is incorrect the
wrong way to view a bool.
Unfortunately you did not include their justification for this
position
On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote:
Walter and Andrei take the position that this is incorrect the
wrong way to view a bool.
Unfortunately you did not include their justification for this
position (if any). To me it would be interesting to know about
the reasoning
On Monday, 12 November 2018 at 15:15:17 UTC, M.M. wrote:
On Monday, 12 November 2018 at 15:03:08 UTC, Adam D. Ruppe
wrote:
On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
The TL;DR is that the DIP is trying to change behavior that
is working as intended.
I thought the whole
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis
wrote:
On Monday, November 12, 2018 2:45:14 AM MST Mike Parker via
Digitalmars-d- announce wrote:
DIP 1015, "Deprecation and removal of implicit conversion from
integer and character literals to bool, has been rejected,
primarily on
On Monday, 12 November 2018 at 15:03:08 UTC, Adam D. Ruppe wrote:
On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
The TL;DR is that the DIP is trying to change behavior that is
working as intended.
I thought the whole point of a DIP is to change behavior that
is working as
On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
The TL;DR is that the DIP is trying to change behavior that is
working as intended.
I thought the whole point of a DIP is to change behavior that is
working as intended. Otherwise, we have a bug fix rather than a
language
That's strange, I thought polysemous literals prefer default
type, not tightest type.
---
auto b=1;
static assert(is(typeof(b)==bool));
---
Error: static assert: is(int == bool) is false
On 2018-11-12 10:45, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from integer
and character literals to bool, has been rejected, primarily on the
grounds that it is factually incorrect in treating bool as a type
distinct from other integral types.
The TL;DR is
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis
wrote:
I was hoping that this DIP was convincing enough, and its
failure is certainly disappointing.
Indeed.
On Monday, November 12, 2018 2:45:14 AM MST Mike Parker via Digitalmars-d-
announce wrote:
> DIP 1015, "Deprecation and removal of implicit conversion from
> integer and character literals to bool, has been rejected,
> primarily on the grounds that it is factually incorrect in
> treating bool as a
DIP 1015, "Deprecation and removal of implicit conversion from
integer and character literals to bool, has been rejected,
primarily on the grounds that it is factually incorrect in
treating bool as a type distinct from other integral types.
The TL;DR is that the DIP is trying to change
75 matches
Mail list logo
