Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread grauzone
a good point. The only drawback in this case is you are constructing information you sometimes do not need or care about. If all you want is whether it succeeded or not, then you don't need two ranges constructed and returned. But therein lies a fundamental tradeoff that cannot be avoided.

Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread bearophile
Christopher Wright: > Just use two functions: find and contains. Or better, define a built in operator, you may call it "in" :-) 'e' in "hello" => true (The compiler may even cache the resulting position somewhere, so a successive find can be very fast). Bye, bearophile

Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread Christopher Wright
downs wrote: Consider this type: struct StringPosition { size_t pos; void opImplicitCast(out size_t sz) { sz = pos; } void opImplicitCast(out bool b) { b = pos != -1; } } Wouldn't that effectively sidestep most problems people have with find returning -1? Or am I missing som

Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread Steven Schveighoffer
On Fri, 15 May 2009 10:30:17 -0400, grauzone wrote: to return a pair struct, but still, what could be simpler than returning an index? It's easy to construct the value you want (before or after), and if you both multiple values, that is also possible (and probably results in simpler code)

Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread grauzone
to return a pair struct, but still, what could be simpler than returning an index? It's easy to construct the value you want (before or after), and if you both multiple values, that is also possible (and probably results in simpler code). All what you can do with the index is 1. compare it ag

Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread Steven Schveighoffer
On Fri, 15 May 2009 09:36:51 -0400, grauzone wrote: downs wrote: Consider this type: struct StringPosition { size_t pos; void opImplicitCast(out size_t sz) { sz = pos; } void opImplicitCast(out bool b) { b = pos != -1; } } Wouldn't that effectively sidestep most problems pe

Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread grauzone
downs wrote: Consider this type: struct StringPosition { size_t pos; void opImplicitCast(out size_t sz) { sz = pos; } void opImplicitCast(out bool b) { b = pos != -1; } } Wouldn't that effectively sidestep most problems people have with find returning -1? Or am I missing som

Re: A case for opImplicitCast: making string search work better

2009-05-15 Thread Steven Schveighoffer
On Fri, 15 May 2009 06:07:10 -0400, downs wrote: Consider this type: struct StringPosition { size_t pos; void opImplicitCast(out size_t sz) { sz = pos; } void opImplicitCast(out bool b) { b = pos != -1; } } Wouldn't that effectively sidestep most problems people have with

A case for opImplicitCast: making string search work better

2009-05-15 Thread downs
Consider this type: struct StringPosition { size_t pos; void opImplicitCast(out size_t sz) { sz = pos; } void opImplicitCast(out bool b) { b = pos != -1; } } Wouldn't that effectively sidestep most problems people have with find returning -1? Or am I missing something? Of cou