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 2016
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 2016
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 2016
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 2016