www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 84: Static Inheritance

reply Atila Neves <atila.neves gmail.com> writes:
 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
Oct 30 2015
next sibling parent reply Shammah Chancellor <shammah.chancellor gmail.com> writes:
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
Oct 30 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
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
Oct 30 2015
parent Shammah Chancellor <s s.com> writes:
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
Oct 30 2015
prev sibling next sibling parent anonymous <anonymous anonymous.com> writes:
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.
Oct 30 2015
prev sibling next sibling parent Daniel N <ufo orbiting.us> writes:
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.
Oct 31 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 31 2015
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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
Oct 31 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 31 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Saturday, 31 October 2015 at 09:49:59 UTC, Walter Bright wrote:
 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.
True. Should I change the DIP? Atila
Nov 02 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/2/2015 5:58 AM, Atila Neves wrote:
 On Saturday, 31 October 2015 at 09:49:59 UTC, Walter Bright wrote:
 Yes. And I think it would have much wider applicability than just struct
 inheritance.
True. Should I change the DIP?
I think that's a good idea.
Nov 02 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 2 November 2015 at 22:21:07 UTC, Walter Bright wrote:
 On 11/2/2015 5:58 AM, Atila Neves wrote:
 On Saturday, 31 October 2015 at 09:49:59 UTC, Walter Bright 
 wrote:
 Yes. And I think it would have much wider applicability than 
 just struct
 inheritance.
True. Should I change the DIP?
I think that's a good idea.
Updated. Atila
Nov 10 2015
parent Colden Cullen <ColdenCullen gmail.com> writes:
On Tuesday, 10 November 2015 at 10:45:16 UTC, Atila Neves wrote:
 [snip]

 Updated.

 Atila
As long as we're talking about syntax features that help this emulate regular inheritance, would it be worth adding a feature like this: template MySuperType(T) { enum MySuperType = validate!T; } void doAThing(MySuperType T)(T val) { } That would effectively lower to: void doAThing(T)(T val) if(__traits(compiles, MySuperType!T)) { } with better error reporting? This would certainly make the code more readable, and would simplify the conditional dramatically if you had more than 1 or 2 template parameters.
Nov 10 2015
prev sibling next sibling parent drug <drug2004 bk.ru> writes:
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.
Oct 31 2015
prev sibling parent Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Saturday, 31 October 2015 at 08:38:01 UTC, Walter Bright wrote:
 <snip>

 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.
+1 !!!!! /Paolo
Oct 31 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-10-30 15:39, 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.
Technically I don't think the "static" keyword is necessary. If it's a template, assume static inheritance. -- /Jacob Carlborg
Oct 31 2015
prev sibling next sibling parent reply Iakh <iaktakh gmail.com> writes:
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
It could be better to extend UDA with checking and diagnostic functions IsInputRange struct myRange {... And some attrs not applicable for all things, extended UDA can handle it
Feb 24
parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 25 February 2016 at 01:57:37 UTC, Iakh wrote:
 On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
 [...]
It could be better to extend UDA with checking and diagnostic functions IsInputRange struct myRange {... And some attrs not applicable for all things, extended UDA can handle it
Scanning for UDAs for a whole project isn't trivial and even worse optional. Atila
Feb 25
parent Iakh <iaktakh gmail.com> writes:
On Thursday, 25 February 2016 at 09:11:58 UTC, Atila Neves wrote:
 On Thursday, 25 February 2016 at 01:57:37 UTC, Iakh wrote:
 On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
 [...]
It could be better to extend UDA with checking and diagnostic functions IsInputRange struct myRange {... And some attrs not applicable for all things, extended UDA can handle it
Scanning for UDAs for a whole project isn't trivial and even worse optional. Atila
I meant extend UDAs to match your proposal. But rules to build failFunc in both cases looks too sophisticated. Simpler version could looks like this: // Predicate: enum bool checkConstraint(bool verbose) = /*Whatever you want*/ struct Struct{ mixin checkConstraint!(isOutputRange, int); // int represents tail template args } mixin checkConstrint!(...) adds this code: static if(!isOutputRange!(Struct, int).checkConstraint!(No.verbose)) { static assert(isOutputRange!(Struct, int).checkConstraint!(Yes.verbose)); }
Feb 25
prev sibling parent Zardoz <luis.panadero gmail.com> writes:
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
+1 !!!
Feb 27