On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
> I'm also tempted to argue that making shared virtually unusable without
> casting it away would be a good idea

It's a bad idea, no two ways about it. The bummer here is that this is the only topic (and one where D gets it right) off of a whole list that Shachar gave, which I'll copy below. His slides are at http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities. Is the talk video anywhere?

> - No RAII support, despite the fact everybody here seems to think that D supports RAII.

So that is slide 4. Could you please give a bit of detail?

> - Recursive const makes many cases where I can use const in C++ (and
> enjoy the protection it provides) simply mutable in D.

(It's transitive, not recursive.) Can't help much here but note that C++'s const being shallow is a source of confusion among beginning programmers. It's a matter in which reasonable people may disagree. I clearly see how someone used to C++'s const wold feel uncomfortable with D's.

> - This one I have not complained about yet. Operator overloads
> stepping on each other's toes. In my case, I have a container (with
> opIndex that accepts a custom type and opOpAssign!"~") and I place in
> it a struct with some operator overloads as well (have not reduced
> the cause yet, hence no previous complaint about this one). So, when
> I write
>
> Container[IndexType] ~= Type;
>
> And the compiler assumes that means:
> Container.opIndexOpAssign!"~"(IndexType, Type);
>
> but since nothing like that is defined, the code doesn't compile. I
> ended up writing (actual code from the Weka code base):
>
> blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i,
> placement.to!SlotIdx(diskIdx)));
>
> Took me almost ten minutes and consulting someone else to find this
> solution.

The opIndexOpAssign family is intentional and arguably a good thing. The semantics of std::map's operator[] are controversial and suboptimal; opIndexOpAssign is specially designed to allow efficient dictionaries and sparse arrays. If you get to reduce the code we'd definitely want to fix whatever bug is there.

> - GC. GC. GC. Some more GC.

You mean there's too much of it? We're on that.

> - Integral type operations promotion and the constant need for casts.

This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP has bugs that we need to fix.

> - No warning for signed/unsigned comparisons. An unfailing source for bugs.

This is actionable too.

> - No ref type.

This you need to live with.

We'd love to make the life easier for Weka, but you need to be careful when mixing things of the D ethos you don't like but won't change (qualifiers, ref) with things that we can improve.

Did you try the .d/.di compile-time table?


Andrei

On Sunday, 14 August 2016 at 00:26:31 UTC, Andrei Alexandrescu wrote:
> On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
>> I'm also tempted to argue that making shared virtually unusable without
>> casting it away would be a good idea
>
> It's a bad idea, no two ways about it. The bummer here is that this is the only topic (and one where D gets it right) off of a whole list that Shachar gave, which I'll copy below. His slides are at http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities. Is the talk video anywhere?

https://youtu.be/yIH_0ew-maI?t=21m34s

On 14/08/16 03:26, Andrei Alexandrescu wrote:
> On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
>> I'm also tempted to argue that making shared virtually unusable without
>> casting it away would be a good idea
>
> It's a bad idea, no two ways about it. The bummer here is that this is
> the only topic (and one where D gets it right) off of a whole list that
> Shachar gave, which I'll copy below. His slides are at
> http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities.
> Is the talk video anywhere?
>
>> - No RAII support, despite the fact everybody here seems to think that
>> D supports RAII.
>
> So that is slide 4. Could you please give a bit of detail?

http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html

>
>> - Recursive const makes many cases where I can use const in C++ (and
>> enjoy the protection it provides) simply mutable in D.
>
> (It's transitive, not recursive.) Can't help much here but note that
> C++'s const being shallow is a source of confusion among beginning
> programmers. It's a matter in which reasonable people may disagree. I
> clearly see how someone used to C++'s const wold feel uncomfortable with
> D's.

I'm quite fine with disagreeing on this point, but I do want to make sure we agree on what it is we disagree about.

My view of the C++ const situation is consistent with C++'s philosophy about pretty much everything, which is this. "We give you very powerful tools to do many things. We do not, however, prevent you from misusing them. Caveat emptor".

C++'s "logical constness" may lead to pretty twisted stuff if misused, but the flip side is that, when used correctly, it can be used quite extensively to give the compiler tools to protect you from mistakes.

D's const, to me (please correct me if I'm wrong), aimed not at helping the compiler help the programmer, but at helping the compiler. It contains a much stronger guarantee, and accordingly, is applicable in much fewer cases.

It is my understanding that we agree on the above. If we do, I can state my opinion, and you are most welcome to disagree with it, and we can call that matter resolved.

In my experience, D's guarantee is too strong, in that it is too often inapplicable. This leads to two bad things happening.

The first is that you can rarely put "const" on anything, meaning you lose the power that C++'s guarantee gave you, and not gain enough in return.

The second is that, since it is so rarely applicable, people tend to forget implementing the const version of methods, even when those are easy. This leads to a situation where, even if const can be applied, it is just too much work to weed out the bugs all over the place this will cause, and people give up.

Compound this with the total mess that is "inout", and I, personally, just gave up. I know I'm not the only one.

>
> The opIndexOpAssign family is intentional and arguably a good thing. The
> semantics of std::map's operator[] are controversial and suboptimal;
> opIndexOpAssign is specially designed to allow efficient dictionaries
> and sparse arrays. If you get to reduce the code we'd definitely want to
> fix whatever bug is there.

I will. I just don't know how long it will take me to get to it. I already tried to recreate it simply with two structs and just the relevant ops, without success (though, now that I think of it, it might have been with a different version than the one that compiles our code).

If you want, since I know you have access, I can send you the line number from which this was taken.

Either way, this is just one example out of many where the interaction between features creates complex situations that either result in not defined (as opposed to undefined) behavior, or result in behavior that may be well defined, but is surprising to the programmer.

>
>> - GC. GC. GC. Some more GC.
>
> You mean there's too much of it? We're on that.

Not exactly, but I have nothing to say here which you don't already know, so let's leave it at that.

>
>> - Integral type operations promotion and the constant need for casts.
>
> This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP
> has bugs that we need to fix.

Won't solve my problems unless VRP's scope is significantly enhanced. Your book said VRP is only defined to work on the same expression it is in. So long as that's the case, it's not a matter of fixing bugs.

Also, I should point out, that I'm not suggesting D allow implicit narrowing conversions. Instead, I think D should drop the pretense that C expressions should maintain their semantics precisely, and stop widening expressions.

I must confess that I have never heard of this rule in C before encountering it in D. Any time I needed some expression to take place with a width larger than the input arguments, I always casted them.

Since this is still necessary for long, I think dropping this rule won't be too big of an issue.

>> - No ref type.
>
> This you need to live with.

Can you expand a little on the rational for that? Also, part of our problems with this is that introspection also does not see refs, which causes the following two functions to report the same signature:

void func1(int arg);
void func2(ref int arg);


>
> We'd love to make the life easier for Weka,

I'd like to make it clear here that I speak of my own experience. I do talk with people, and some of the engineers share some of my criticism. However, please don't think that just because I'm more vocal than others in Weka, it means that my opinions are shared by all. Please treat my posts here as my own.

 but you need to be careful
> when mixing things of the D ethos you don't like but won't change
> (qualifiers, ref) with things that we can improve.
>
> Did you try the .d/.di compile-time table?

Not my task, so what I'm writing here is second hand knowledge from one random water cooler talk. Please excuse me if I'm making gross misrepresentations of reality here.

From what I understand, there is a problem with the way imports are put in the di files. In particular, take the following code:

import some.struct: SomeStruct;
import some.other.struct: SomeOtherStruct;

SomeStruct func() {
   SomeOtherStruct a(3);
   return a.some;
}

The ideal di for it would be:

import some.struct: SomeStruct;

SomeStruct func();

Sadly, the actual di also contains the totally unnecessary:

import some.other.struct: SomeOtherStruct;

The result is that the di contains too many imports, and no gains are made vis compilation times.

Shachar

On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
> On 14/08/16 03:26, Andrei Alexandrescu wrote:
>> On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
>>> I'm also tempted to argue that making shared virtually unusable without
>>> casting it away would be a good idea
>>
>> It's a bad idea, no two ways about it. The bummer here is that this is
>> the only topic (and one where D gets it right) off of a whole list that
>> Shachar gave, which I'll copy below. His slides are at
>> http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities.
>>
>> Is the talk video anywhere?
>>
>>> - No RAII support, despite the fact everybody here seems to think that
>>> D supports RAII.
>>
>> So that is slide 4. Could you please give a bit of detail?
>
> http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html

OK. One thing we can't stress enough is that everything - talks, slides, newsgroup posts - about a bug in the language definition or implementation must be in support of an issue. No issue no honey. I submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf and preapproved it. Please carry future considerations there.

> I'm quite fine with disagreeing on this point, but I do want to make
> sure we agree on what it is we disagree about.
>
> My view of the C++ const situation is consistent with C++'s philosophy
> about pretty much everything, which is this. "We give you very powerful
> tools to do many things. We do not, however, prevent you from misusing
> them. Caveat emptor".
>
> C++'s "logical constness" may lead to pretty twisted stuff if misused,
> but the flip side is that, when used correctly, it can be used quite
> extensively to give the compiler tools to protect you from mistakes.
>
> D's const, to me (please correct me if I'm wrong), aimed not at helping
> the compiler help the programmer, but at helping the compiler. It
> contains a much stronger guarantee, and accordingly, is applicable in
> much fewer cases.
>
> It is my understanding that we agree on the above. If we do, I can state
> my opinion, and you are most welcome to disagree with it, and we can
> call that matter resolved.
>
> In my experience, D's guarantee is too strong, in that it is too often
> inapplicable. This leads to two bad things happening.
>
> The first is that you can rarely put "const" on anything, meaning you
> lose the power that C++'s guarantee gave you, and not gain enough in
> return.
>
> The second is that, since it is so rarely applicable, people tend to
> forget implementing the const version of methods, even when those are
> easy. This leads to a situation where, even if const can be applied, it
> is just too much work to weed out the bugs all over the place this will
> cause, and people give up.
>
> Compound this with the total mess that is "inout", and I, personally,
> just gave up. I know I'm not the only one.

I understand. One thing we want to do to improve on that is to deduce const for template methods. See https://issues.dlang.org/show_bug.cgi?id=16389.

>> The opIndexOpAssign family is intentional and arguably a good thing. The
>> semantics of std::map's operator[] are controversial and suboptimal;
>> opIndexOpAssign is specially designed to allow efficient dictionaries
>> and sparse arrays. If you get to reduce the code we'd definitely want to
>> fix whatever bug is there.
>
> I will. I just don't know how long it will take me to get to it. I
> already tried to recreate it simply with two structs and just the
> relevant ops, without success (though, now that I think of it, it might
> have been with a different version than the one that compiles our code).
>
> If you want, since I know you have access, I can send you the line
> number from which this was taken.
>
> Either way, this is just one example out of many where the interaction
> between features creates complex situations that either result in not
> defined (as opposed to undefined) behavior, or result in behavior that
> may be well defined, but is surprising to the programmer.

This being a matter of perception, there's no disagreement here. To turn this into something actionable it would be great if you thought of ways to simplify said interaction without breaking code (e.g. by removing unnecessary constraints).

>>> - Integral type operations promotion and the constant need for casts.
>>
>> This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP
>> has bugs that we need to fix.
>
> Won't solve my problems unless VRP's scope is significantly enhanced.
> Your book said VRP is only defined to work on the same expression it is
> in. So long as that's the case, it's not a matter of fixing bugs.

It's a matter of school of thought. C and C++ allow implicit casts that lose information. C# and Java do not. Each has pluses and minuses. D is on the C# and Java side, with VRP which reduces the number of explicit casts needed. Here again we're not talking about a bug in the language or the "right" or "wrong" language design, it's just a matter in which different languages do different things.

> Also, I should point out, that I'm not suggesting D allow implicit
> narrowing conversions. Instead, I think D should drop the pretense that
> C expressions should maintain their semantics precisely, and stop
> widening expressions.

This will not happen.

> I must confess that I have never heard of this rule in C before
> encountering it in D.

Which rule?

> Any time I needed some expression to take place
> with a width larger than the input arguments, I always casted them.

So then why do you complain D asks for "too many" casts?

> Since this is still necessary for long, I think dropping this rule won't
> be too big of an issue.

You kind of lost me there. So which rule?

>>> - No ref type.
>>
>> This you need to live with.
>
> Can you expand a little on the rational for that?

The "ref" attribute has been a fundamental part of the language for too long.

> Also, part of our
> problems with this is that introspection also does not see refs, which
> causes the following two functions to report the same signature:
>
> void func1(int arg);
> void func2(ref int arg);

I actually think you can do introspection on any argument to figure whether it has "ref".

>> We'd love to make the life easier for Weka,
>
> I'd like to make it clear here that I speak of my own experience. I do
> talk with people, and some of the engineers share some of my criticism.
> However, please don't think that just because I'm more vocal than others
> in Weka, it means that my opinions are shared by all. Please treat my
> posts here as my own.

There are some good points that we could easily agree need to be improved. At some point you must get in gear and submit some issues to move forward on things important to Weka.

> From what I understand, there is a problem with the way imports are put
> in the di files. In particular, take the following code:
>
> import some.struct: SomeStruct;
> import some.other.struct: SomeOtherStruct;
>
> SomeStruct func() {
>    SomeOtherStruct a(3);
>    return a.some;
> }
>
> The ideal di for it would be:
>
> import some.struct: SomeStruct;
>
> SomeStruct func();
>
> Sadly, the actual di also contains the totally unnecessary:
>
> import some.other.struct: SomeOtherStruct;
>
> The result is that the di contains too many imports, and no gains are
> made vis compilation times.

I think you forgot to mention the issue number :o).


Andrei

On Sun, 14 Aug 2016 08:18:08 +0300, Shachar Shemesh wrote:
> The first is that you can rarely put "const" on anything, meaning you lose the power that C++'s guarantee gave you, and not gain enough in return.

I can often put const on things. However, it's an added step, the compiler doesn't prompt me, and I can't add it everywhere. The result is that I make things const-correct about 2% of the time.

If function parameters were const by default, that would prompt me to try to make my code const-correct. If there were a module-level annotation I could use to turn on const-by-default, I would use it.

On 14/08/16 17:07, Andrei Alexandrescu wrote:
> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
>>> So that is slide 4. Could you please give a bit of detail?
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
>>
> 
> OK. One thing we can't stress enough is that everything - talks, slides, newsgroup posts - about a bug in the language definition or implementation must be in support of an issue. No issue no honey. I submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf and preapproved it. Please carry future considerations there.

Thank you. To be fair, though, you might want to close it as a duplicate of https://issues.dlang.org/show_bug.cgi?id=14246



> I understand. One thing we want to do to improve on that is to deduce const for template methods. See https://issues.dlang.org/show_bug.cgi?id=16389.

Personally, I also think that inout should stop acting like it is a fourth form of protection.
> Here again we're not talking about a bug in the language
> or the "right" or "wrong" language design, it's just a matter in which
> different languages do different things.
> 
>> Also, I should point out, that I'm not suggesting D allow implicit narrowing conversions. Instead, I think D should drop the pretense that C expressions should maintain their semantics precisely, and stop widening expressions.
> 
> This will not happen.

I had a whole list of places where D already isn't compatible with C for a statement that compiles in both. I cannot find it. I'll start a new thread when I do.

> 
>> I must confess that I have never heard of this rule in C before encountering it in D.
> 
> Which rule?

The rule that says "ubyte + ubyte = uint".

>> Can you expand a little on the rational for that?
> 
> The "ref" attribute has been a fundamental part of the language for too long.

I'm sorry, I simply don't understand that answer. How is turning "ref" into a type modifier hinder you in any way? No old compiling code breaks as a result.

> 
>> Also, part of our
>> problems with this is that introspection also does not see refs, which
>> causes the following two functions to report the same signature:
>>
>> void func1(int arg);
>> void func2(ref int arg);
> 
> I actually think you can do introspection on any argument to figure whether it has "ref".
> 
>>> We'd love to make the life easier for Weka,
>>
>> I'd like to make it clear here that I speak of my own experience. I do talk with people, and some of the engineers share some of my criticism. However, please don't think that just because I'm more vocal than others in Weka, it means that my opinions are shared by all. Please treat my posts here as my own.
> 
> There are some good points that we could easily agree need to be improved. At some point you must get in gear and submit some issues to move forward on things important to Weka.

The problem is that many of those points are contended (or, at least, used to be). If you read through the thread I pointed to regarding the destructor issue, for example, you will see that people actually argue that the way D currently does things is the correct way to do things.

If I submit an issue to the forum, and get back the reply "that's a know thing, and that's on purpose", I don't see any point in submitting an issue.

> 
>> From what I understand, there is a problem with the way imports are put in the di files. In particular, take the following code:
>>
>> import some.struct: SomeStruct;
>> import some.other.struct: SomeOtherStruct;
>>
>> SomeStruct func() {
>>    SomeOtherStruct a(3);
>>    return a.some;
>> }
>>
>> The ideal di for it would be:
>>
>> import some.struct: SomeStruct;
>>
>> SomeStruct func();
>>
>> Sadly, the actual di also contains the totally unnecessary:
>>
>> import some.other.struct: SomeOtherStruct;
>>
>> The result is that the di contains too many imports, and no gains are made vis compilation times.
> 
> I think you forgot to mention the issue number :o).

Like I said, I'm just a relay on that front. I'll try to get the people actually working on it to submit an issue.

Shachar

On 8/14/16 2:03 PM, Shachar Shemesh wrote:
> On 14/08/16 17:07, Andrei Alexandrescu wrote:
>> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
>>>> So that is slide 4. Could you please give a bit of detail?
>>>
>>> http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
>>>
>>
>> OK. One thing we can't stress enough is that everything - talks, slides,
>> newsgroup posts - about a bug in the language definition or
>> implementation must be in support of an issue. No issue no honey. I
>> submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf
>> and preapproved it. Please carry future considerations there.
>
> Thank you. To be fair, though, you might want to close it as a duplicate
> of https://issues.dlang.org/show_bug.cgi?id=14246

Thanks. For now I raised both to critical.

>> I understand. One thing we want to do to improve on that is to deduce
>> const for template methods. See
>> https://issues.dlang.org/show_bug.cgi?id=16389.
>
> Personally, I also think that inout should stop acting like it is a
> fourth form of protection.

I'm not a fan of inout either. We need to think collectively of ways to move things forward from where we are to a better place.

>>> Also, I should point out, that I'm not suggesting D allow implicit
>>> narrowing conversions. Instead, I think D should drop the pretense that
>>> C expressions should maintain their semantics precisely, and stop
>>> widening expressions.
>>
>> This will not happen.
>
> I had a whole list of places where D already isn't compatible with C for
> a statement that compiles in both. I cannot find it. I'll start a new
> thread when I do.

That would be very helpful.

>>> I must confess that I have never heard of this rule in C before
>>> encountering it in D.
>>
>> Which rule?
>
> The rule that says "ubyte + ubyte = uint".

That will not happen. It would break tons of code in subtle ways. You are a competent engineer so you know better than asking for it.

>>> Can you expand a little on the rational for that?
>>
>> The "ref" attribute has been a fundamental part of the language for too
>> long.
>
> I'm sorry, I simply don't understand that answer. How is turning "ref"
> into a type modifier hinder you in any way? No old compiling code breaks
> as a result.

Of course it breaks all code that introspects e.g. parameter types and finds "ref T" instead of "T". It is a fundamental change to the language that is also questionable on its own (C++ has and continues to have inordinate complications because of references being an almost-type). Pick your fights properly, and fight them well.

>>> Also, part of our
>>> problems with this is that introspection also does not see refs, which
>>> causes the following two functions to report the same signature:
>>>
>>> void func1(int arg);
>>> void func2(ref int arg);
>>
>> I actually think you can do introspection on any argument to figure
>> whether it has "ref".

Just making sure you read the above. Please give it a look.

>> There are some good points that we could easily agree need to be
>> improved. At some point you must get in gear and submit some issues to
>> move forward on things important to Weka.
>
> The problem is that many of those points are contended (or, at least,
> used to be). If you read through the thread I pointed to regarding the
> destructor issue, for example, you will see that people actually argue
> that the way D currently does things is the correct way to do things.

Did anyone in the leadership say so? If not, you're safe to ignore it; statistically anything suggested herein will find a strong opponent. I'm with you on this, and Walter is too (just confirmed via email). The issues are preapproved. I've also raised the issues to critical.

> If I submit an issue to the forum, and get back the reply "that's a know
> thing, and that's on purpose", I don't see any point in submitting an issue.

If you get it from Walter and myself, yes. Otherwise, again, ignore and press on. Again: choose your fights and fight them well. I know in your heart of hearts have an understanding of what you can change and what you cannot.

>>> The result is that the di contains too many imports, and no gains are
>>> made vis compilation times.
>>
>> I think you forgot to mention the issue number :o).
>
> Like I said, I'm just a relay on that front. I'll try to get the people
> actually working on it to submit an issue.

Thanks. I should add that as long as the .di does not import the .d, the slowdown due to the computed table will not occur. So the worry is not warranted.


Andrei

On 8/14/2016 11:03 AM, Shachar Shemesh wrote:
>> Which rule?
> The rule that says "ubyte + ubyte = uint".

Many people are surprised by this rule, but it is deeply embedded in C and C++.

In C99,

-------------------------------
6.3.1.8 Usual Arithmetic Conversions

Then the following rules are applied to the promoted operands:

If both operands have the same type, then no further conversion is needed.

Otherwise, if both operands have signed integer types or both have unsigned
integer types, the operand with the type of lesser integer conversion rank is
converted to the type of the operand with greater rank.

Otherwise, if the operand that has unsigned integer type has rank greater or
equal to the rank of the type of the other operand, then the operand with
signed integer type is converted to the type of the operand with unsigned
integer type.

Otherwise, if the type of the operand with signed integer type can represent
all of the values of the type of the operand with unsigned integer type, then
the operand with unsigned integer type is converted to the type of the
operand with signed integer type.

Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type.
--------------------------------------------

This rule was retained for D to make it easier to translate code from C/C++ to D. Changing the rule could result in subtle and invisible bugs for such translations and for C/C++ programmers who are so used to the integral promotion rules that they aren't even really aware of reliance upon them.

The reason C/C++ programmers, even experienced ones, are often unaware of this rule is there is another rule, implicit narrowing, so:

    byte = byte + byte;

compiles without complaint. The trouble comes when byte has a value, say, 255, and the sum is 510. The assignment silently chops it to byte size, and 254 is stored in the result.

For D, we decided that silently converting 510 to 254 would not be acceptable. Hence an explicit cast would be required,

    byte = cast(byte)(byte + byte);

where the user presumably knows what he's doing.

On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
> For years, i was travelling along Golang, Rust, Perl, Ruby, Python, PHP, JScript, JVM Languages.
> Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more that i can't remember.
>
> I'm 24 years old, my first lang was PHP and VBasic then C,C++ and i first heard about D after 2005 when i was 14-15 years old.
>
> I always ignored D, i prejudiced that D failed, because nobody were talking about it. I decided to check it yesterday, it has excellent documentation, i almost covered all aspects. I think D is much better than the most of the other popular langs. It's clear as JScript, Swift, Julia and PHP, also it's capable enough as C,C++. I think D deserves a bigger community.
>
> Why people need NodeJS, Typescript etc, when there is already better looking lang?
> Everyone talking about how ugly is Golang. So why people are going on it? Performance concerns? Why languages that are not backed up by huge companies are looking like they failed?

That guy who was very popular in your high school, you remember? How did he become so popular?

D doesn't have much of what it takes to become popular that is why it is not :) Just ask yourself, why is JavaScript so popular? How about PHP?

On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d wrote:
> On 8/14/16 2:03 PM, Shachar Shemesh wrote:
> > On 14/08/16 17:07, Andrei Alexandrescu wrote:
> >> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
> >>> I must confess that I have never heard of this rule in C before encountering it in D.
> >>
> >> Which rule?
> >
> > The rule that says "ubyte + ubyte = uint".
>
> That will not happen. It would break tons of code in subtle ways. You are a competent engineer so you know better than asking for it.

No offense, but that comes across as pretty condescending. I agree that changing the integer promotion rules would be very risky, but that's the sort of response that seems more likely to offend than to educate or convince.

- Jonathan M Davis