Why D is not popular enough?

[Andrei Alexandrescu via Digitalmars-d]

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