On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
- At this point the question I'd personally suggest to be
evaluated is "does this proposal enable enough useful
designs?". A good check would be to try taking some of your
projects and see if having DIP1000 approved and implemented
could improve them.
There's a use-case that relates to some of our discussions
together in another context, about structs or classes that borrow
data via ref:
struct MyWrapperStruct (T)
{
private T* data;
public this (ref T input)
{
this.data = &input;
}
// ... other functionality relies on
// this.data being valid throughout
// the lifetime of the struct
// note, we could probably avoid everyone
// having to use raw pointers as above if
// we could use scope properties to create
// a `Ref` borrowed-pointer type that would
// complement the existing `Unique`
}
I don't see any examples touching on this, but it would be very
useful for implementing e.g. InputRange structs which cannot be
copied by value, yet which need to be usable with UFCS range
chains.
Any chance the proposal authors could add some examples of how
scope could affect class/struct fields which borrow data by
reference (meaning the class/struct instance should not escape
the scope of the input data)?
