On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
> I will start:
>
>    -- Better compiler errors, better compiler errors, better compiler errors.
>
>
> I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible).
>
> To illustrate my point:
>
> - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png
>
> - Now compare that with an error produced by rustc:
> https://cdn.pbrd.co/images/H0q6bLi.png
>
>
> Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.


This topic was there for so many times.
Tuples, async/await, maybe monad (eg. int?), conditional dereferencing qualifier?.identifier, coalescence operator return x ?? 42;
better properties, default safety, explicit throw funcs, runtime reflection, ARC instead of GC, so support, ...

The community is quite conservative about implementing new stuff in D.

Look at for more info:
http://forum.dlang.org/thread/sapqaonpjseeykdczmvw@forum.dlang.org?page=1
http://forum.dlang.org/thread/ot1q8b$23pt$1@digitalmars.com?page=1



BTW: I decided to make my own language rather than forcing the community to implement something what I would like to see in the lang. https://github.com/Rikarin/Rin

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
> I will start:
cut...
> Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.

I would like to have a complete and well-defined memory model.
And its proper implementation in the compiler.

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
>    -- Better compiler errors, better compiler errors, better compiler errors.


This is the only thing I greatly care about anymore. Biggest problem D has in real world use.

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
>    -- Better compiler errors, better compiler errors, better compiler errors.

Very much so.

I actually made a list a day or two ago. Some of it is more speculative than concrete, though:

* unicode categories to determine what can be an identifier (there's no reason not to support, say, Canadian aboriginal syllabaries; it would just be too much work to list out each range of glyphs)
* concepts / compile-time interfaces (makes ranges easier to deal with and document)
* @safe by default
* function parameters are const scope by default (I recall this was a major request when const was first introduced)
* mixin templates (a template designed to be mixed in is likely not to work if simply invoked; this also gets us most of what people have been asking for with macros)
* possibly, block syntax for functions and templates whose last parameter is a function or alias

On 12/29/2017 9:29 AM, Adam D. Ruppe wrote:
> On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
>>    -- Better compiler errors, better compiler errors, better compiler errors.
> 
> 
> This is the only thing I greatly care about anymore. Biggest problem D has in real world use.

This is not actionable. What is actionable is filing bugzilla enhancement requests with specific examples.

On 12/28/2017 11:53 PM, IM wrote:
> Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.

Diverging from the:

  file(line): message

format is problematic because a lot of editors rely on that to position the editor on the offending line.

On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright wrote:
> On 12/28/2017 11:53 PM, IM wrote:
>> Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.
>
> Diverging from the:
>
>   file(line): message
>
> format is problematic because a lot of editors rely on that to position the editor on the offending line.

It's easy to detect whether the compiler is invoked in a TTY.
Even if this turns out to be tricky, showing more helpful information to the user with a special flag (e.g. `--explain` or `--detailed`) is a way to go forward.

On Fri, 29 Dec 2017 13:34:14 -0800, Walter Bright wrote:

> On 12/28/2017 11:53 PM, IM wrote:
>> Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.
> 
> Diverging from the:
> 
>    file(line): message
> 
> format is problematic because a lot of editors rely on that to position the editor on the offending line.

I think the idea of the OP is that the message should be better; not that it should have an identical format to the Rust error.

    file(line): better message

isn't going to mess with anybody's tools.

I noticed the Rust error has a code, too (E0308); if better error messages are too difficult to implement, assigning codes to error types and documenting them on the wiki could be helpful. Once you've dealt with an error type, the messages aren't that bad, but having documentation for the first time you run into it would be nice.

Somewhat-related question out of curiosity: is there ever a time the error message "template instance foo!(bar) error instantiating" is actually needed? I've always seen it paired with a message that actually describes the problem, so is just noise.

On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote:
> AFAIK Rust doesn't have templates, but generics. Generics usually have much cleaner error messages because they are mostly used for generic functions and classes, meanwhile templates can do that too but much, much more, but when they break, you get entire paragraphs of template errors.

Templates are bad because they write code for you. And it's that code you don't write that could have errors. It's a double edge sword.

Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc...

On Friday, 29 December 2017 at 21:56:26 UTC, Seb wrote:
> On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright wrote:
>> On 12/28/2017 11:53 PM, IM wrote:
>>> Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.
>>
>> Diverging from the:
>>
>>   file(line): message
>>
>> format is problematic because a lot of editors rely on that to position the editor on the offending line.
>
> It's easy to detect whether the compiler is invoked in a TTY.
> Even if this turns out to be tricky, showing more helpful information to the user with a special flag (e.g. `--explain` or `--detailed`) is a way to go forward.

Being in an editor does not imply being in a TTY.

Atila