On Sunday, 11 June 2017 at 19:51:11 UTC, ketmar wrote:

> i think, that something like `__constraint(condition, "message")` is ok, and it should be built-in, just like `__traits()`. so compiler can collect those messages, and only show 'em if the matcher is failed to find anything. yeah, another hack in interpreter, but fairly small, and should solve "what constraint is really failed" problem.

This is really nice. I like it better than my suggestion.

On 6/11/17 12:35 PM, Stanislav Blinov wrote:
> On Sunday, 11 June 2017 at 16:28:23 UTC, Timon Gehr wrote:
>
>> I'd prefer
>>
>> bool msg(bool constraint, string message){ return constraint; }
>>
>> This does not require the compiler to dive into a branch it wouldn't
>> consider otherwise, and the pairing of constraint to message is less
>> ad-hoc.
>
> Where were you while Steven was destroying me? :)
>
> http://forum.dlang.org/thread/mcxeymbslqtvfijxirmy@forum.dlang.org

Heh, I both like the idea of switching the constraints to something that identifies easily a single test of the constraint instead of a lambda that can fail for any number of reasons, and also think we still do not need a message. i.e.:

is(typeof(lvalueOf!R.front)) && "must support front"

"must support front" seems pretty obvious from the test.

-Steve

On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote:
> // Also possible (no change to the language)
> enum bool isInputRange(R) =
>     is(typeof((ref R r) => r)) && msg("must be copyable")


Or how about

enum bool isInputRange(R) =
      isCopyable!R &&
      supportsBoolEmpty!R &&
      supportsFront!R &&
      supportsPopFront!R;

and the compiler just calls out which condition didn't match?

>     && is(typeof(lvalueOf!R.popFront)) && msg("must support back");

hey look you already messed up the string by repeating it.

On Monday, 12 June 2017 at 00:13:46 UTC, Adam D. Ruppe wrote:
> On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote:
>> // Also possible (no change to the language)
>> enum bool isInputRange(R) =
>>     is(typeof((ref R r) => r)) && msg("must be copyable")
>
>
> Or how about
>
> enum bool isInputRange(R) =
>       isCopyable!R &&
>       supportsBoolEmpty!R &&
>       supportsFront!R &&
>       supportsPopFront!R;
>
> and the compiler just calls out which condition didn't match?

Much better. Probably could be a bit more generic than that :)

>
>>     && is(typeof(lvalueOf!R.popFront)) && msg("must support back");
>
> hey look you already messed up the string by repeating it.

Exactly my point.

-Steve

On 6/11/2017 5:13 PM, Adam D. Ruppe wrote:
>        supportsFront!R &&

That doesn't work because there may be a local symbol:

    T front(R r) { }

which will not be in scope in supportsFront().

On Monday, 12 June 2017 at 07:18:30 UTC, Walter Bright wrote:
> On 6/11/2017 5:13 PM, Adam D. Ruppe wrote:
>>        supportsFront!R &&
>
> That doesn't work because there may be a local symbol:
>
>     T front(R r) { }
>
> which will not be in scope in supportsFront().

That is a problem regardless of the constraint.

Even if we are clever enough to construct the constraint to workaround this issue, code that uses such ranges will not compile.

-Steve

On 06/12/2017 03:18 AM, Walter Bright wrote:
> On 6/11/2017 5:13 PM, Adam D. Ruppe wrote:
>>        supportsFront!R &&
> 
> That doesn't work because there may be a local symbol:
> 
>      T front(R r) { }
> 
> which will not be in scope in supportsFront().

Yah, this was part of the original design: migrate all checks to std.traits. At a point I realized that queries of the form "does a.b work?" need to be accompanied by passing a number of modules to import in order to resolve possible UFCS for "b". At the moment I had a standard library artifact import a user-defined module, I decided things got too odd and gave up on that. -- Andrei

On 6/11/17 1:32 PM, Sebastiaan Koppe wrote:

> What about using ddoc?
> 
> enum bool isInputRange(R) =
>      is(typeof((ref R r) => r)) /// must be copyable
>      && is(ReturnType!((R r) => r.empty) == bool) /// must support bool empty
>      && is(typeof(lvalueOf!R.front)) /// must support front
>      && is(typeof(lvalueOf!R.popFront)) /// must support back

If there's going to be compiler magic, this seems like a sensible syntax--documenting constraints is a good idea anyway, particularly for those of us who aren't is-expression masters.

On Mon, Jun 12, 2017 at 10:35:59AM -0700, David Gileadi via Digitalmars-d wrote:
> On 6/11/17 1:32 PM, Sebastiaan Koppe wrote:
> 
> > What about using ddoc?
> > 
> > enum bool isInputRange(R) =
> >      is(typeof((ref R r) => r)) /// must be copyable
> >      && is(ReturnType!((R r) => r.empty) == bool) /// must support bool
> > empty
> >      && is(typeof(lvalueOf!R.front)) /// must support front
> >      && is(typeof(lvalueOf!R.popFront)) /// must support back
> 
> If there's going to be compiler magic, this seems like a sensible syntax--documenting constraints is a good idea anyway, particularly for those of us who aren't is-expression masters.

+1, I like this idea much better than any of the others proposed so far. No need for additional syntax, reuse ddoc comment syntax for something that, ostensibly, could be considered documentation.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On Monday, 12 June 2017 at 17:35:59 UTC, David Gileadi wrote:
> On 6/11/17 1:32 PM, Sebastiaan Koppe wrote:
>
>> What about using ddoc?
>> 
>> enum bool isInputRange(R) =
>>      is(typeof((ref R r) => r)) /// must be copyable
>>      && is(ReturnType!((R r) => r.empty) == bool) /// must support bool empty
>>      && is(typeof(lvalueOf!R.front)) /// must support front
>>      && is(typeof(lvalueOf!R.popFront)) /// must support back
>
> If there's going to be compiler magic, this seems like a sensible syntax--documenting constraints is a good idea anyway, particularly for those of us who aren't is-expression masters.

Yeah, I had meant to mention the compiler magic involved. I suppose the magic is far less than anything else though, since the compiler already associates surrounding docs to code (right?).