making a struct an inputRange with free functions

[jmh530]

On Thursday, 19 April 2018 at 01:33:26 UTC, Jonathan M Davis 
wrote:
> [snip]
>
> Occasionally, that aspect of importing and UFCS can be 
> annoying, but on the whole, I don't really see why it matters 
> much, particularly when actually having the free functions 
> available would be an enormous change to how imports work and 
> could cause a ton of other problems. It would mean that code 
> would be affected by which code imported it rather than just 
> the code that it imports, and at that point, you effectively 
> lose control over what's going on. It would mean that just like 
> C/C++ #includes, you couldn't rely on the module being the same 
> every time you imported it. Even if the effect were limited to 
> templated code, it would mean that two supposedly identical 
> instantiations of a template would not necessarily be identical 
> anymore, and they'd have to be recompiled in every module that 
> used them. It would be a disaster in the making. mixins are the 
> closest that we get to that, but in that case, the programmer 
> is specifically stating that they want to reuse that code 
> directly in their own module as if it were declared there 
> rather than using stuff from other modules. Occasionally, that 
> might be limiting, but without those restrictions, you 
> basically don't have a module system anymore. And with mixins, 
> you have control over what affects your module, whereas having 
> the code that imports a module affect it would be more like 
> mixing in code from the outside.
>
> And in any case, IMHO, the range API functions aren't really 
> functions that make much sense as free functions anyway. 
> They're not generic, and they're very much tied to the type 
> that they go with - just like opEquals, opAssign, or toString 
> are tied to the type. They're inherently pretty much the 
> opposite of generic. And even if the import rules somehow let 
> you have them as free functions without it causing problems, 
> what would it buy you? The only situation I can think of where 
> it might be useful is if you're dealing with a type that you 
> can't control and thus can't add the member functions to. But 
> in that case, you can always just wrap that type in another 
> type that does declare the range API. So, I don't think that 
> much is lost by not being able to use UFCS to make something a 
> range.
>
> - Jonathan M Davis

I get that range functions are very much tied to the type. My 
default is almost always to include them as member functions, and 
I don't favor any big breaking changes.

With respect to this thread, my thinking had gone to that mention 
of anemic domain models on the announce board a few days ago [1]. 
If free functions can't fully replace member functions, then this 
anemic domain model approach would be limited in D.

[1] 
https://forum.dlang.org/thread/kawrnpsyjugwwtknqauv@forum.dlang.org