Re: Implementing Template Restrictions in Different Way
On Monday, 1 September 2014 at 22:46:52 UTC, Nordlöw wrote: Is this a other/newer preferred way to describe the template restriction, using for example __traits(compiles, ...)? Is is(typeof(... AFAIK, those produce the same results 99% of the time. The only cases where they differ are borderline buggy. the fastest way to do this? Are you talking about constraints, or implementation of safeSkipOver? BTW: Is there a way to prevent the calls to r1.length and r2.length in this case? Hum... Are you writing this function because skipOver will actually fail? AFAIK, it shouldn't. We should fix skipOver...
Re: Implementing Template Restrictions in Different Way
On Monday, 1 September 2014 at 22:46:52 UTC, Nordlöw wrote: BTW: Is there a way to prevent the calls to r1.length and r2.length in this case? Also, this assumes your ranges have front at all. AFAIK, skipOver operates on forward ranges. Related: Your condition could fail if R1/R2 are strings of un-matching widths.
Re: Implementing Template Restrictions in Different Way
On Tuesday, 2 September 2014 at 10:22:49 UTC, monarch_dodra wrote:
the fastest way to do this?
Are you talking about constraints, or implementation of
safeSkipOver?
The constraint.
Hum... Are you writing this function because skipOver will
actually fail? AFAIK, it shouldn't. We should fix skipOver...
Yes, I'm writing this wrapper because call to r.front in
bool skipOver(alias pred = a == b, R, E)(ref R r, E e)
if (is(typeof(binaryFun!pred(r.front, e
{
if (!binaryFun!pred(r.front, e))
return false;
r.popFront();
return true;
}
fails when r is empty.
It believe it should be
if (r.empty || !binaryFun!pred(r.front, e))
right? Should I do a PR?
Re: Implementing Template Restrictions in Different Way
On Tuesday, 2 September 2014 at 11:41:51 UTC, Nordlöw wrote:
On Tuesday, 2 September 2014 at 10:22:49 UTC, monarch_dodra
wrote:
the fastest way to do this?
Are you talking about constraints, or implementation of
safeSkipOver?
The constraint.
In that case, I'm not sure what you mean by fastest in the
context of constraints, which are compile-time.
Hum... Are you writing this function because skipOver will
actually fail? AFAIK, it shouldn't. We should fix skipOver...
Yes, I'm writing this wrapper because call to r.front in
bool skipOver(alias pred = a == b, R, E)(ref R r, E e)
if (is(typeof(binaryFun!pred(r.front, e
{
if (!binaryFun!pred(r.front, e))
return false;
r.popFront();
return true;
}
fails when r is empty.
It believe it should be
if (r.empty || !binaryFun!pred(r.front, e))
right? Should I do a PR?
I think so yes. That's the R/E version though. Is the R/R
version also subject to this issue?
Re: Implementing Template Restrictions in Different Way
On Tuesday, 2 September 2014 at 12:14:01 UTC, monarch_dodra wrote: In that case, I'm not sure what you mean by fastest in the context of constraints, which are compile-time. With performance I mean compilation speed. I think so yes. That's the R/E version though. Is the R/R version also subject to this issue? No, it's only the R/E that lacks emptyness check. PR: https://github.com/D-Programming-Language/phobos/pull/2481
Implementing Template Restrictions in Different Way
Forgetting to do
import std.functional: binaryFun;
before trying to compile
bool skipOverSafe(alias pred = a == b, R1, R2)(ref R1 r1, R2 r2)
@safe pure if (is(typeof(binaryFun!pred(r1.front, r2.front
{
return r1.length = r2.length skipOver!pred(r1, r2); //
TODO: Can we prevent usage of .length?
}
unittest
{
auto s1 = Hello world;
assert(!skipOverSafe(s1, Ha));
}
gives no clue about the missing import in the diagnostics.
Is this a other/newer preferred way to describe the template
restriction, using for example __traits(compiles, ...)? Is
is(typeof(...
the fastest way to do this?
BTW: Is there a way to prevent the calls to r1.length and
r2.length in this case?
