Re: DIP 84: Static Inheritance
On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote: From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqo...@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/qvofihzmappftdiwd...@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 !!!
Re: DIP 84: Static Inheritance
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));
}
Re: DIP 84: Static Inheritance
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
Re: DIP 84: Static Inheritance
On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
From the discussion here:
http://forum.dlang.org/post/tgnxocozkurfvmxqo...@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/qvofihzmappftdiwd...@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
Re: DIP 84: Static Inheritance
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.
Re: DIP 84: Static Inheritance
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
Re: DIP 84: Static Inheritance
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
Re: DIP 84: Static Inheritance
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.
Re: DIP 84: Static 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.
Re: DIP 84: Static Inheritance
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.
Re: DIP 84: Static Inheritance
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.
Re: DIP 84: Static Inheritance
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
Re: DIP 84: Static Inheritance
On 2015-10-30 15:39, Atila Neves wrote: From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqo...@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/qvofihzmappftdiwd...@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
Re: DIP 84: Static Inheritance
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.
Re: DIP 84: Static Inheritance
On Saturday, 31 October 2015 at 08:38:01 UTC, Walter Bright wrote: 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
DIP 84: Static Inheritance
From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqo...@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/qvofihzmappftdiwd...@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
Re: DIP 84: Static Inheritance
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/tgnxocozkurfvmxqo...@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/qvofihzmappftdiwd...@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
Re: DIP 84: Static Inheritance
On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote: From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqo...@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/qvofihzmappftdiwd...@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
Re: DIP 84: Static Inheritance
On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote: From the discussion here: http://forum.dlang.org/post/tgnxocozkurfvmxqo...@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/qvofihzmappftdiwd...@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.
Re: DIP 84: Static Inheritance
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: 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
