On Sunday, 17 April 2016 at 16:44:50 UTC, Nick Treleaven wrote:
The @safe troika is a good design (except @safe should be the
default), the implementation is lacking though. Ideallists want
to make @safe strict now, but break code sometimes even without
basic workarounds for memory-safe code. Pragmatists want to
avoid breakage but make the subset of @safe code wider, making
the definition more complex. There seems to be a stalemate.
Yeah, but for example rust deals with the same problem with a
single keyword.
scope, if implemented for reference types, wouldn't scale well.
It should be the default, with __escape meaning scope(false). I
think it's an uphill battle arguing for this, but it is crucial
to avoiding GC without runtime checks. At least for non-GC code
in a general way.
scope (for function parameters) cannot be implemented in
backwards compatible way because a lot of code uses in (which is
const^scope)
I think @property is OK. I think the controversy at the time
was about optional brackets in function calls, which is
different.
First @property + compiler switch, now @property + deprecated
switch. When should I use property? For all the getters? Should I
start with property or with member access? Does it even matter
because of optional parens? Why do I even need to care about this?
Sure all of the things I've mentioned can be defended. The
question is not whether they have a usecase (because all of them
do), but whether return on investment for them is good enough and
how they interact with the rest of the language.
CTFE does what you'd expect it to do - constant folding is
intuitive and requires little to no code changes. Purity is
orthogonal to the rest of the language (modulo corner cases) and
enables some patterns for immutable value creation. Those (and
others - the stuff that's good doesn't come to mind because it
works) have higher ROI and aren't as much of a burden for library
writers.
