From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqofnn@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint that it was meant to, such as `isInputRange`. So I submitted a PR (https://github.com/D-Programming-Language/phobos/pull/3677), it's been there ever since and doesn't seem like it'll go anywhere from the discussion (http://forum.dlang.org/post/qvofihzmappftdiwdaue@forum.dlang.org).

So the only other way is a DIP (http://wiki.dlang.org/DIP84) for language and compiler support for static inheritance. It's backwards-compatible and IMHO worth looking at.

Please let me know what you think.

Atila

On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
> From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqofnn@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint that it was meant to, such as `isInputRange`. So I submitted a PR (https://github.com/D-Programming-Language/phobos/pull/3677), it's been there ever since and doesn't seem like it'll go anywhere from the discussion (http://forum.dlang.org/post/qvofihzmappftdiwdaue@forum.dlang.org).
>
> So the only other way is a DIP (http://wiki.dlang.org/DIP84) for language and compiler support for static inheritance. It's backwards-compatible and IMHO worth looking at.
>
> Please let me know what you think.
>
> Atila

Atila,  did you get a chance to look at the std.experimental.concepts work I was doing?

It's very similar to what you seem to want, but the diagnostic messages are really annoying to use as you have to make a default template that the user can fall through to:

https://github.com/schancel/phobos/blob/4ca5d075f31b8e09ba71ac2a53ff56ff0c4ac5b9/std/experimental/concepts.d

-Shammah

On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
> From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqofnn@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint that it was meant to, such as `isInputRange`. So I submitted a PR (https://github.com/D-Programming-Language/phobos/pull/3677), it's been there ever since and doesn't seem like it'll go anywhere from the discussion (http://forum.dlang.org/post/qvofihzmappftdiwdaue@forum.dlang.org).
>
> So the only other way is a DIP (http://wiki.dlang.org/DIP84) for language and compiler support for static inheritance. It's backwards-compatible and IMHO worth looking at.
>
> Please let me know what you think.
>
> Atila

To be honest. The idea of having a library fix error messages seems sort of like a band-aid solution rather than a real solution. Don't get me wrong, I use band aids, but I think the DIP solution is a more proper approach. As far as the DIP, I like what was proposed.

> Structs can't currently inherit and so wouldn't need static. However, it might be preferable to require it anyway for parity with classes:

I would say I agree that it should be required, just for consistency sake.

On Friday, 30 October 2015 at 15:45:00 UTC, Shammah Chancellor wrote:
> On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
>> From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqofnn@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint that it was meant to, such as `isInputRange`. So I submitted a PR (https://github.com/D-Programming-Language/phobos/pull/3677), it's been there ever since and doesn't seem like it'll go anywhere from the discussion (http://forum.dlang.org/post/qvofihzmappftdiwdaue@forum.dlang.org).
>>
>> So the only other way is a DIP (http://wiki.dlang.org/DIP84) for language and compiler support for static inheritance. It's backwards-compatible and IMHO worth looking at.
>>
>> Please let me know what you think.
>>
>> Atila
>
> Atila,  did you get a chance to look at the std.experimental.concepts work I was doing?
>
> It's very similar to what you seem to want, but the diagnostic messages are really annoying to use as you have to make a default template that the user can fall through to:
>
> https://github.com/schancel/phobos/blob/4ca5d075f31b8e09ba71ac2a53ff56ff0c4ac5b9/std/experimental/concepts.d
>
> -Shammah

I took a look. I don't think we should or need to use classes and therefore dynamic polymorphism to solve the problem of checking for adherence to a static interface.

Mostly all I want is for the compiler to tell me why something doesn't compile - it already knows it but is hiding the information from me.

Atila

On Friday, 30 October 2015 at 16:44:15 UTC, Atila Neves wrote:
> On Friday, 30 October 2015 at 15:45:00 UTC, Shammah Chancellor wrote:
>> On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
>>> From the discussion here: <snip>
>
> I took a look. I don't think we should or need to use classes and therefore dynamic polymorphism to solve the problem of checking for adherence to a static interface.
>
> Mostly all I want is for the compiler to tell me why something doesn't compile - it already knows it but is hiding the information from me.
>
> Atila

I'm not advocating for the implementation, but the dynamic polymorphism isn't required.  The class is just a skeleton for specifying the definition in a clear way.  See the unit test:

https://github.com/schancel/phobos/blob/4ca5d075f31b8e09ba71ac2a53ff56ff0c4ac5b9/std/experimental/concepts.d#L280-L303

On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
> So the only other way is a DIP (http://wiki.dlang.org/DIP84) for language and compiler support for static inheritance. It's backwards-compatible and IMHO worth looking at.
>
> Please let me know what you think.
>
> Atila

I found a counter proposal which requires no code changes.

As you all know, certain constructs in D, only determine if something is possible or not, but give no error messages, this is implemented with a "gagging" mechanism.

I didn't look at the code for many months, but it roughly goes like this:
1) Enable Gag
2) Check if the code is valid
3) Disable Gag
4) Repeat above for all candidates.
5) If there's no unique match, print an error.
6) Exit

The key idea is that once we reach 5, we know that we will fail, now instead of Exiting the compiler we could re-run the failing chain, only this time without any GAG:s.

a) No user-code impact, all old software will immediately benefit.
b) We will get the full error messages.
c) Compilation time of working programs stays the same, because this only kicks in once we are going to abort anyway.

On 10/30/2015 7:39 AM, Atila Neves wrote:
> Please let me know what you think.

Thanks for writing this. I think it's a very creative solution.

I've used the static assert technique you mentioned in the DIP. It solves the first part of the problem, that of shifting the detection of the error from the usage of the struct to the definition of the struct.

The remaining problem is the suppression of the error message detailing why it failed the test. Perhaps a more general solution is a __traits(compiles, expr) feature that does not suppress error messages.

On Saturday, 31 October 2015 at 08:38:01 UTC, Walter Bright wrote:
> On 10/30/2015 7:39 AM, Atila Neves wrote:
>> Please let me know what you think.
>
> Thanks for writing this. I think it's a very creative solution.
>
> I've used the static assert technique you mentioned in the DIP. It solves the first part of the problem, that of shifting the detection of the error from the usage of the struct to the definition of the struct.
>
> The remaining problem is the suppression of the error message detailing why it failed the test. Perhaps a more general solution is a __traits(compiles, expr) feature that does not suppress error messages.

Interesting. Like this perhaps?

struct Struct : isInputRange ->

static assert(__traits(compilesNoSupress, isInputRange!Struct));
struct Struct
//...

Atila

On 10/31/2015 2:21 AM, Atila Neves wrote:
> Interesting. Like this perhaps?
>
> struct Struct : isInputRange ->
>
> static assert(__traits(compilesNoSupress, isInputRange!Struct));
> struct Struct
> //...

Yes. And I think it would have much wider applicability than just struct inheritance.

31.10.2015 11:38, Walter Bright пишет:
> Perhaps a more general solution is a
> __traits(compiles, expr) feature that does not suppress error messages.
Yes, please. Using msgpack I often get message that call to fromMsgpack/toMsgpack is failed but have no clue why. If it just typo it's ok, but when you serialize a complex structure and the compile error is caused by some nested structure it becomes tricky and annoying.