March 08, 2019
On Friday, 8 March 2019 at 06:45:24 UTC, Nicholas Wilson wrote:
> But it also returns false if the expression is false
>
> `is(T==int)` could return false because T is an error AST node, because T is undefined in the context or because T is not `int`. I'm missing how you would handle the latter case.

Ah.

I guess in that case, since this is a compiletime expression and can change its type at will, you could simply just return `false`.
March 08, 2019
Am Fri, 08 Mar 2019 05:46:01 +0000 schrieb Nicholas Wilson:

> On Thursday, 7 March 2019 at 22:09:29 UTC, Johannes Pfau wrote:
>> The DIP seems kind of intrusive to me. And Parsing a DNF
> 
> The DIP formalises a constraint in a _CNF_, not DNF.

You're right of course, I guess I was too tired when I wrote that.

>> form has one major drawback: For quite some time now we actually
>> advised people to refactor their constraints into external helper
>> functions, in order to have nicer ddoc. E.g.
>> isDigest!X instead of isOutputRange!X && ...
> 
> Yes, but this is for a single concept for a single parameter. Real constraints deal with multiple parameters and conjunctions and disjunction of concepts, hence the CNF formalisation. The rest of what you describe is great, but completely orthogonal.
> 
> I have made this comment before: https://github.com/dlang/DIPs/pull/131#issuecomment-416555780
> 
>> So now, we'd have to recommend the exact opposite.
> 
> This follows only for a single parameter.

OK, I see. For multiple parameters a CNF form is indeed the natural description. However, the DIP probably wouldn't be needed with traits(constraintsCheck) as multiple error reporting would also work with a CNF of implements!T or other constraints. One thing a simple traits(constraintsCheck) can probably not handle easily is pointing out which of the implements!T calls caused the errors, though if we detect CNF in the compiler that could work. Really difficult are more complicated constructs such as (isSomething!(A, B) || isSomething!(A, C)). Here traits(constraintsCheck) would produce all messages for both checks if both fail.

-- 
Johannes
March 08, 2019
On Friday, 8 March 2019 at 08:19:41 UTC, Johannes Pfau wrote:
> OK, I see. For multiple parameters a CNF form is indeed the natural description. However, the DIP probably wouldn't be needed with traits(constraintsCheck) as multiple error reporting would also work with a CNF of implements!T or other constraints. One thing a simple traits(constraintsCheck) can probably not handle easily is pointing out which of the implements!T calls caused the errors,

That is why this is orthogonal to the DIP, nothing stops us doing both.

> though if we detect CNF in the compiler that could work. Really difficult are more complicated constructs such as (isSomething!(A, B) || isSomething!(A, C)).

No, _really_ difficult constraints are recursive on variable arguments

ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack, Rs needles)
if (isForwardRange!R
    && Rs.length > 0
    && isForwardRange!(Rs[0]) == isInputRange!(Rs[0])
    && is(typeof(startsWith!pred(haystack, needles[0])))
    && (Rs.length == 1
    || is(typeof(countUntil!pred(haystack, needles[1 .. $])))))

https://github.com/dlang/phobos/blob/master/std/algorithm/searching.d#L768

> Here traits(constraintsCheck) would produce all messages for both checks if both fail.

List the output for a predicate that is invalid for the second needle, or a second needle that is an input range but not a forward range or a second needle that is not an input range but fails for some other reason.

In the first case you're in an is expression and typeof and the constraint comes from the failed constraint of the recursion of the current template that depends on another template (startsWith)

The second still doesn't enable expressing the fact the countUntil requires needles to either be elements or forward ranges, which is not at all obvious from the expression used to encode the sub-constraint.

The third you _have to_ use the CNF property or else you'll emit errors for unrelated things.

March 11, 2019
On Monday, 4 March 2019 at 14:50:11 UTC, Adam D. Ruppe wrote:
> One of the reddit comments posted this link:
>
> https://elm-lang.org/blog/compiler-errors-for-humans
>
> Wow, those error messages are MUCH better than D has. Want my opinion on the best thing D should change for productivity? Completely overhaul the error messages.

Another relevant blog post, this one about error message improvements in GCC 9: https://developers.redhat.com/blog/2019/03/08/usability-improvements-in-gcc-9/.

Not in the same league as what is described for Elm, but there may be useful ideas.

March 12, 2019
On Monday, 11 March 2019 at 23:41:13 UTC, Jon Degenhardt wrote:
> Not in the same league as what is described for Elm, but there may be useful ideas.

Still very nice, much better than dmd has. Look, they use color to highlight relevant information instead of pointless syntax!

I'm so jealous I am seriously considering forking the compiler just to improve my own productivity instead of waiting on upstream to take error messages seriously.
March 12, 2019
On Tuesday, 12 March 2019 at 00:07:19 UTC, Adam D. Ruppe wrote:
> I am seriously considering forking the compiler just to improve my own productivity instead of waiting on upstream to take error messages seriously.

Please don't, we'd love to have those patches!

I'm a bit busy at the moment, but I've added better error messages to the agenda for dconf. So once we have some vision and direction we should be ready to make some serious progress, one major thing I think will help is to have tools to auto-update the test suite, I hate how over prescriptive it is.
March 12, 2019
On Monday, 11 March 2019 at 23:41:13 UTC, Jon Degenhardt wrote:
> Not in the same league as what is described for Elm, but there may be useful ideas.

Oh wow, these are good. I might actually switch back to GCC for my C++ projects. I still remember, a few years ago, when GCC diagnostics didn't even include line contents, only error lines.
March 12, 2019
On Tuesday, 12 March 2019 at 00:40:32 UTC, Nicholas Wilson wrote:
> one major thing I think will help is to have tools to auto-update the test suite, I hate how over prescriptive it is.

./test/run.d AUTO_UPDATE=1

(works with the Makefile too)
March 12, 2019
On Tuesday, 12 March 2019 at 06:33:55 UTC, Seb wrote:
> On Tuesday, 12 March 2019 at 00:40:32 UTC, Nicholas Wilson wrote:
>> one major thing I think will help is to have tools to auto-update the test suite, I hate how over prescriptive it is.
>
> ./test/run.d AUTO_UPDATE=1
>
> (works with the Makefile too)

Thanks, could you add that to the dlang bot's message? I'm going to forget that otherwise.
March 12, 2019
On Tuesday, 12 March 2019 at 06:50:45 UTC, Nicholas Wilson wrote:
> On Tuesday, 12 March 2019 at 06:33:55 UTC, Seb wrote:
>> On Tuesday, 12 March 2019 at 00:40:32 UTC, Nicholas Wilson wrote:
>>> one major thing I think will help is to have tools to auto-update the test suite, I hate how over prescriptive it is.
>>
>> ./test/run.d AUTO_UPDATE=1
>>
>> (works with the Makefile too)
>
> Thanks, could you add that to the dlang bot's message? I'm going to forget that otherwise.

No, we can't add the entire README to every message.
Just remember to look here (the testsuite's README):

https://github.com/dlang/dmd/blob/master/test/README.md#automatically-update-the-test_output-segments
1 2 3 4 5
Next ›   Last »