On Thursday, 20 March 2014 at 00:09:51 UTC, bearophile wrote:
Joseph Rushton Wakeling:
* std.random2.adaptor, random "adaptors" such as
randomShuffle,
randomSample, etc.
Please don't use stuttering names like
"std.random2.randomShuffle". "std.random2.shuffle" is enough.
Agreed.
`randomShuffle` can be made a deprecated alias: This way,
"random2" should still be mostly "drop in replacement", but we
won't drag along the bad names.
My own feeling is that ultimately it is a responsibility of
the language to offer nice ways to allocate classes without
necessarily relying on new or the GC.
I don't think the language is yet there. So I think currently
this is not a good idea.
I think there is 0 doubt that reference semantics is the way to
go. An advantage of using class is that it is still *possible* to
place them on the stack with Scoped, or with some future language
mechanic. On the other hand, if we implement as reference
structs, then that's that.
Furthermore, even in terms of performance, I think a heap
allocated PRNG will still flat-out beat the value based one, if
only because of the size of the damn thing.
That said, being able to allocate them on the malloc heap, and
not the GC heap, would be (IMO) also a valid design.
A simple and dumb design might be to still implement them with
value semantic but:
1. Disable postblit.
2. Make .save() return a "Random*"
This would mean
1. No dangers of accidental copy.
2. Range* is a ForwardRange.
3. Trivially allows GC/malloc/stack allocation.
With good aliases ("alias Random = RadomImpl*;"), and a "make!"
template we could make the "default useage" transparent to this
mechanism yet make it easy to get our hands under the hood.
But at this point, we are really beating around the bush on this
issue. There are two things for sure:
1. Reference semantics by default.
2. There comes a point where we have to move forward.
I didn't check the code yet, but a "middle ground" could be to
make all constructors private, and disable T.init. Then, we force
construction through a make! template.
This might not be what's most convenient, but it would allow us
to potentially change the design at a later stage, without
breaking user code.
Do you have a simple but very fast function that generates
uniforms in [0.0, 1.0]? :-)
AFAIK, the allocation issue is only for ranges? "uniform" is just
a function, I don't think it affected by the issue. Even if you
are operating on a "passed range", either ranges are reference
semantics, and you take by value, or they are value semantic, and
you take by ref. Either way, you have to pay for the indirection.
