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/kawrnpsyjugwwtknq...@forum.dlang.org
