Why D is not popular enough?

[Shachar Shemesh via Digitalmars-d]

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