October 31, 2015
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
October 31, 2015
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


November 02, 2015
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
November 02, 2015
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.

November 10, 2015
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
November 11, 2015
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.
February 25, 2016
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
February 25, 2016
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
February 25, 2016
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));
}
February 27, 2016
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 !!!
1 2
Next ›   Last »