On Tuesday, 5 May 2015 at 21:04:22 UTC, Justin Whear wrote:
Dates, times, durations, regular expressions, tokens, lazy
generators,
digests, vectors, really any type that provides a
interpretation/behavior
wrapper around one or more trivially copyable types.
That's a very nice list, thank you, it *was* helpful. Still, I
have some issues with it, maybe we can improve it.
* Dates, times, durations, vectors -> still somewhat numeric. I
can add two weeks to a date, 3 seconds to a duration, etc. (for
types which are not at all numeric it would probably make no
difference what value are assigned which bit patterns, while for
more numeric types the bit patterns must have some regularity to
be able to efficiently implement operations like addition, etc.)
* Regular expressions -> I have no idea what you have in mind for
this one; even after looking at std.regex...
* Tokens -> On the one hand, I think this could be an excellent
example, since it's a case where the bit pattern is arbitrary
(because it generally has no numeric properties). On the other
hand, I could see people arguing that just using an int is
perfectly fine, so it doesn't benefit from a custom type. Do
notice that, even in D, an enum converts without a cast to an
int, so the fact that an enum might be used to list the possible
abstract values (the tokens) doesn't quite make it a completely
independent type, IMHO.
* lazy generators -> explain, please?
* digests -> do you mean the digest output, or the digest
function state?
Frankly, the real divide in my mind is
polymorphic/non-polymorphic, not
by-reference vs by-value, though I will occasionally use `final
class` if
I want a convenience reference type around a resource.
Aren't you arguing against yourself? In those cases you wanted
your type to have reference semantics, even though it wasn't a
polymorphic type. Doesn't that counterexample prove that
polymorphic/non-polymorphic is just an heuristic, while the
value/ref distinction is more fundamental?
