On Friday, 9 November 2012 at 05:25:12 UTC, Jonathan M Davis
wrote:
Given that a range requires a very specific set of functions, I
find it highly unlikely that anything which isn't a range will
qualify as one.
I've had it happen to me several times. Let me show you some code
from my dom.d:
mixin template JavascriptStyleDispatch() {
string opDispatch(string name)(string v = null) if(name
!= "popFront") { // popFront will make this look like a range. Do
not want.
class Element {
// name != "popFront" is so duck typing doesn't think
it's a range
@property string opDispatch(string name)(string v = null)
if(name != "popFront") {
}
struct CssRule {
string opDispatch(string nameGiven)(string value = null)
if(nameGiven != "popFront") {
}
From prototype.d:
class PrototypeObject {
// the constraint is needed otherwise the Variant
constructor fails
@property ref PrototypeObject opDispatch(string name)()
if(name != "length") {
}
(I'm not sure if this last one is a range problem, because it was
Variant that was confused, but the dom ones definitely were).
Of course, they all have something in common: an open opDispatch.
But that's a valid D feature so surely I'm not the only one using
it.
Every one of those constraints come from it actually being a
problem at one point or another.
