On Wednesday, 19 April 2017 at 14:45:59 UTC, Meta wrote:
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov
wrote:
Non-copyable and immovable types will have to be explicitly
initialized, as if they had @disable this(), as they can't
even be initialized with .init:
It's
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov
wrote:
Non-copyable and immovable types will have to be explicitly
initialized, as if they had @disable this(), as they can't even
be initialized with .init:
It's an interesting idea but I can't even begin to fathom how
much code
On Wednesday, 19 April 2017 at 08:52:45 UTC, kinke wrote:
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov
wrote:
But it is always assumed that a value can be moved.
It's not just assumed, it's a key requirement for structs in D,
as the compiler can move stuff automatically this
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov
wrote:
But it is always assumed that a value can be moved.
It's not just assumed, it's a key requirement for structs in D,
as the compiler can move stuff automatically this way (making a
bitcopy and then eliding the postblit ctor
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov
wrote:
I'd very much like to hear your thoughts on this, good/bad, if
it already was proposed, anything. If it's found feasible, I
could start a DIP. Destroy, please.
I don't have comments about the syntax, but I did want this
is undesirable (e.g. std.typecons.Scoped - class instance on the
stack). What if a concept of immovable types was introduced? I.e.
structs you can initialize, possibly copy, but never move. Having
such types would e.g. disallow returning instances from
functions, or make things like std.typecons.Scoped
