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? (Genuine question.)
>
> It probably depends on where someone is from (asinine isn't considered a big insult where I live [rural US]).

And to clarify what I meant by asinine: issue 10560 being the correct behavior is that. I was not meaning to call Walter extremely foolish (although now I can see how it can be interpreted as that and if he took it that way: I'm sorry).

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 => <implicit-convert-to-int><exact-match-on-f(int)>
>> 2) A.a => <implicit-convert-to-int><implicit-convert-to-short><exact-match-on-f(short)>
>> 
>> 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 it basically convert as long as you can? Does D actually do a "find the shortest path via implicit conversions to an overload" algorithm?
>
> It is not a shortest path algorithm. It's simply the enum is converted to the base type and the base type is matched against the parameter type.

Ok, thanks!
>
>
>>> One could have <implicit conversion><exact> be treated as "better than" <implicit conversion><implicit conversion>, 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 examples.
>> 
>> Interesting. This seems simpler intuitively (shorter path, pick it), so I'm wondering if there're any links you can point to that describe what these problems were?
>
> No, I simply remember the discussions about it in the early 90's. Yes, it seems to intuitively make sense, but if you look at real C++ code and try to figure it out, it's a nightmare. There can also be multiple paths of conversions, and loops in those paths. There's a quadratic problem when there are multiple parameters.

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 missing some edge case maybe, but I can't figure it out.

Pus, it seems to work as "expected" with alias this. So I kinda wonder what reasons there could be to not make it work as expected for other scenarios.

struct B {
    enum A : int { a }
    alias b = A.a;
    alias b this;
}

void f(short) {}
void f(int) {}

f(B()); // does what anyone would expect

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 missing some edge case maybe, but I can't figure it out.
>
> Pus, it seems to work as "expected" with alias this. So I kinda wonder what reasons there could be to not make it work as expected for other scenarios.
>
> struct B {
>     enum A : int { a }
>     alias b = A.a;
>     alias b this;
> }
>
> void f(short) {}
> void f(int) {}
>
> f(B()); // does what anyone would expect

Hahaha! That is hilarious! for the curious https://run.dlang.io/is/fqlllS

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 person stupid or foolish. That's just throwing
> insults around. If an idea or decision is bad, then it should be shown as to
> why it's bad, and if it is indeed a terrible idea, then the arguments
> themselves should make that obvious without needing to throw insults around.
> 
> It's not always easy to avoid calling ideas stupid when you get emotional
> about something, but the stronger the language used, the more likely it is
> that you're going to get a strong emotional response out of the other person
> rather than a logical, reasoned discussion that can come to a useful
> conclusion rather than a flame war, and asinine is a pretty strong word.
> It's the sort of word that's going to tend to get people mad and insulted
> rather than help with a logical argument in any way - which is why Walter
> called in unprofessional.

Exactly right.

It's not that I'm angry about this (I'm not), I've been around too long to get annoyed at this sort of thing. I'm pointing out that using such tactics will produce the following reactions:

1. professionals (i.e. people that matter) will ignore you

2. the recipient will get angry with you, will go out of his way to refuse to acknowledge your position, and will entrench himself deeper in his position

3. discourage professionals (i.e. people that matter) from participating in the forums

4. you'll find yourself interacting solely with other egg-throwers, accomplishing nothing

None of these are a desirable result.

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 in-sincere, I don't know how to properly apologize in text-form).

Thank you. I gladly accept.

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` is a manifest constant of type `A` with a value of `127`.
>
> Remember that `A` is not an `int`.

What is ": int" doing, only specifying the size?

-- 
/Jacob Carlborg

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 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 making an automatic decision. Not "just one more" match level, but just...don't match. If there are multiple matching overloads, just error out. Don't try to be clever and surprise people, just tell the user to be more explicit.

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 this, maybe the
> compiler shouldn't be making an automatic decision. Not "just one more"
> match level, but just...don't match. If there are multiple matching
> overloads, just error out. Don't try to be clever and surprise people,
> just tell the user to be more explicit.
> 

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

-Steve

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 considered as being completely distinct from integer types. The fact that you can ever pass 0 or 1 to a function that accepts bool without a cast is a problem in and of itself. But it doesn't really surprise me that Walter doesn't agree on that point, since he's never agreed on that point, though I was hoping that this DIP was convincing enough, and its failure is certainly disappointing.

I'm at a loss to see any significant advantage to having bool as a part of the language itself if it isn't deliberately isolated from `integral types`.