On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote:
On 17/03/2015 10:31, Almighty Bob wrote:
It's far more useful for csvReader to return a type I know and
can use than it is to obscure the return type for the sake of
some philosophical ideal of increasing encapsulation.
Part of the art of API design is to hide implementation where
it's not necessarily needed. Designers might err on the side
of hiding things, because how you expose something is
important as it has to be maintained indefinitely. If they
expose everything then the internals can never be redesigned
for better performance, etc.
They don't increase encapsulation. The public members of a
voldomort type are still public, you still have to code to the
API of the return type whether it's a regular or voldomort
type. You can keep as much private or public in either case as
you like.
All they do take the typename out of circulation, they make
life harder for the user. There's no benefit. None.
But at least the library author can stroke his chin a feel smug
that there's one less type in the modules' namespace.
Totally missing the point. The crux of the matter is this:
changing a voldemort type (assuming the public semantics are the
same) is not a breaking API change, because no-one else's code
ever names it.
Admittedly this is sort-of true for any function that returns
auto and doesn't document its return type, but that is by
convention (the type is always readable in the relevant .d or .di
file) whereas using a voldemort type enforces it.
Note that if you really want a name to use in your code:
alias IotaFloat = typeof(iota(0f, 2f, 1f));
