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