Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
September 01, 2014 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? |
September 02, 2014 Re: Implementing Template Restrictions in Different Way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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... |
September 02, 2014 Re: Implementing Template Restrictions in Different Way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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.
|
September 02, 2014 Re: Implementing Template Restrictions in Different Way | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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? |
September 02, 2014 Re: Implementing Template Restrictions in Different Way | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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? |
September 02, 2014 Re: Implementing Template Restrictions in Different Way | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 |
Copyright © 1999-2021 by the D Language Foundation