UDAs - Restrict to User Defined Types?

[Jonathan M Davis]

On Friday, November 09, 2012 01:44:51 Nick Sabalausky wrote:
> On Thu, 08 Nov 2012 21:10:55 -0800
> 
> Walter Bright <newshound2 at digitalmars.com> wrote:
> > Many algorithms (at least the ones in Phobos do) already do a check
> > to ensure the inputs are the correct kind of range. I don't think
> > you'll get very far trying to use a range that isn't a range.
> 
> It can't check semantics. If something "looks" like a range function,
> but wasn't written with the explicit intent of actually being one, then
> it's a crapshoot as to whether the semantics actually conform. But
> the ducktyping D does do will go and blindly assume.

True, but how likely is it that a type will define all of the necessary range 
functions and _not_ supposed to be a range? The type must define a specific set 
of functions, and those functions must compile with at isInputRange at 
minimum, which checks more than just the function names, and the more complex 
the range required, the more functions are required and the more specific the 
tests are (e.g. while isInputRange doesn't test the type of front, 
isBidirectionalRange does test that front and back have the same type). The 
odds of accidentally matching isInputRange are already low, but they dwindle 
to nothing pretty darn quickly as the type of range is more complex, simply 
because the number of functions and the tests made on them increase to the 
point that there's pretty much no way that anything will ever accidentally 
pass them without being intended to be a range.

I just don't think that the odds of anything accidentally passing the range 
traits - even isInputRange - are very high at all. And given that ranges are 
part of the standard library, I don't think that there's really any excuse for 
anyone using the names of range functions for something else, not more than 
one or two of them at once anyway. So, I really think that any worries about 
this are unfounded.

- Jonathan M Davis