Future of D

[Basile B.]

On Wednesday, 16 December 2020 at 12:30:06 UTC, ddcovery wrote:
> On Wednesday, 16 December 2020 at 10:39:38 UTC, Max Haughton 
> wrote:
>> On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:
>>> On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:
>>>
>>>> [...]
>>>
>>> From my personal experience, the complication comes because D 
>>> libraries and compiler itself follows the "convention" over 
>>> "contract" way (similar to the "convention" over 
>>> "configuration" with ruby on rails :-) ).
>>>
>>> [...]
>>
>> Consider that C++ has only just got template constraints 
>> (concepts), and they have been at the design stage, roughly, 
>> since I was born on to this earth.
>>
>> We have template constraints already, we could have nicer 
>> template constraints as a fairly trivial library solution 
>> (composing them isn't hard), but ultimately more templates 
>> puts a lot of pressure on the compiler for not much benefit.
>
> As a good friend told me 20 years ago: "strong typing allows 
> you to see an application as a set of gears that fit together 
> perfectly"... with templates, you don't know the shape of the 
> gears until compiler tries to build them... this opens a lot of 
> possibilities and introduces some problems.
>
> Problem with "template constraints" is it tries to give a 
> "declarative" vision of something that is solved imperatively  
> (if you generate a "isEquatable" constraint... you must 
> generate imperative static code to check what "isEquatable" 
> means) and this is a barrier for "intelligense" systems like 
> VSCode plugins that helps developers to check it's code BEFORE 
> it is compiled.  The plugin can't determine what "isEquatable" 
> means and can't help you saying "Person class is not 
> Equatable"... a template constraint is a "custom" blackbox 
> that, semantically, doesn't associate language dependent 
> declarative concepts (like inheritance or interfaces).  Correct 
> me if I'm in an error... I am not really experienced D 
> developer.
>
> If you will work with D, you must be aware about this kind of 
> "small" barriers.

Yes your analysis is correct. The barrier to a better 
intellisense is clearly that it would have to to check 
expressions semantics and be able to evaluate them statically, 
just like the compiler does.

Static interfaces for example would make intellisense easier (not 
need to rewrite the ASTs !) but would provide a less modular 
subset of what is possible with D (also known as static 
introspection).

Honestly if I was to create a language I would be **very** 
prudent with the adoption of templates (and even generics) and 
would rather choose static interfaces. For intelissense the 
simple contract that class X implements the behavior defined by 
static interface Y and for a specified type is simple enough.

But for D it's too late. You can have a library solution for 
static interfaces but then it will be template-based and that 
don't help.