So what does (inout int = 0) do?
QAston via Digitalmars-d
digitalmars-d at puremagic.com
Sun Apr 17 10:39:48 PDT 2016
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.
More information about the Digitalmars-d
mailing list