std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

Jonathan M Davis newsgroup.d at jmdavisprog.com
Tue Jun 23 03:55:14 UTC 2020


On Monday, June 22, 2020 9:37:51 PM MDT Jonathan M Davis via Digitalmars-d 
wrote:
> Now, as far as basic input ranges go, having them be classes isn't
> necessarily a problem, since basic input ranges are essentially reference
> types by their very nature (or at least, they can't be value types). If they
> could have value semantics, they could be forward ranges. In fact, in some
> ways, it would be nice to require that basic input ranges be classes, since
> then it would be easy to introspect a basic input range vs a forward range,
> and it would ensure that basic input ranges have full-on reference
> semantics, but it also would result in heap allocations that are not
> currently necessary - particularly in cases where it would currently work
> to use a pseudo-reference type rather than full-on reference type. So,
> while it would be very nice to be able to require that basic input ranges
> be classes, I doubt that it's actually reasonable to do so. Either way, it
> shouldn't be a problem to allow basic input ranges to be classes. It's just
> with forward ranges that it's a problem, but struct wrappers should solve
> that problem.

On further reflection though, one advantage of disallowing classes as ranges
entirely (thus requiring a struct wrapper even for basic input ranges) would
be that we could require that the init value be a valid, empty range, which
we can't do as long as we allow classes. Still, the fact that basic input
ranges and forward ranges inherently have different copying semantics means
that they don't have quite the same problem with classes.

- Jonathan M Davis





More information about the Digitalmars-d mailing list