On Thursday, 18 November 2021 at 14:56:40 UTC, rumbu wrote:

interface I { void foo(); }

void bar(I i)
{
   i: foo;
}

class C: I { void foo() {} }
struct S: I { void foo() {} }

C c = new C();
S s = new S();

void callMe(I i) { i.foo }

callMe(c); // compiler will call callMe as usual
callMe(s); // compiler will generate and call a specialized callMe(S i)

Is the point here to make sure that a struct implements a given interface? Because, if so:

https://github.com/atilaneves/concepts#using-a-d-interface-to-specify-compile-time-template-constraints

I hadn't thought about functions that can take a dynamic or static type though, which is interesting.

class C
{
    int _fld;
    int prop() {return _fld;}
    void prop(int x) { _fld = x; }
}

C c = new C();
c.prop += 42;  ///oops!

Works with ref prop() { return _fld; }.

switch (JSONValue)
{
   case JSONNumber n: writeln ("I have a number %s", n);
   case JSONString s when s.Length > 100 : writeln("long string");
   case JSONString s: writeln("short string");
}

std.sumtype?

On Thursday, 18 November 2021 at 13:37:28 UTC, Atila Neves wrote:

Ahem...

On Thursday, 18 November 2021 at 20:13:44 UTC, Vladimir Marchevsky wrote:

So... what's missing is updating the docs? :P

On Thursday, 18 November 2021 at 19:32:36 UTC, Atila Neves wrote:

The whole point of properties is to hide private state. Exposing a private member for direct mutation is generally a bad idea.

On Friday, 19 November 2021 at 10:21:35 UTC, Max Samukha wrote:

Exactly.
What I would expect from a "real" property is that

prop += 5;

is automatically lowered to

prop(prop() + 5); // function style

or direct

auto tmp = prop; tmp += 5; prop = tmp;

or whatever - but would work only if there is both a getter and a setter.
And if only one of the two is implemented, a fitting error message should be emitted like
"no setter for prop available" or "no getter for prop available".

It should NEVER EVER set a property through the getter!!!
ref prop() { ... } is a very bad anti-pattern.
If "const" is missing or a reference is returned from a getter (a @property function without parameter) this should be a compile error!
Unless that is given I don't consider @property to be a ready-to-use feature.

On Friday, 19 November 2021 at 11:14:46 UTC, Dom DiSc wrote:

And btw. taking the address of a property (the whole point why this feature was abandoned which would otherwise be very easy to implement) should simply be forbidden also.
What should that be anyway? The address of the getter? Or that of the setter? Or that of the private member (that may not even exist)?!?
Properties simulate a value but protect it by allowing only specific operations on it (either get or set or both, but maybe with complicated processing of the assigned value).
Why should it allow such an immersive operation as taking its address?!?

If at all, we may allow for a third property function, that simulates an address of a value - but I can't think of a valid usecase for such a thing... through the address you can do everything to the simulated object, so why not making it public in the first place?

On Friday, 19 November 2021 at 11:14:46 UTC, Dom DiSc wrote:

If you want to hide the field from public use, then just don't expect it to behave like a public field.

If you want to have += and other operators that affect the private field, you could return a wrapper that does this and saves the field.

This behavior of @properties should just be explained a lot better, and that's it.

Why is it bad?

Best regards,
Alexandru.

On Friday, 19 November 2021 at 14:30:39 UTC, Alexandru Ermicioi wrote:

It violate encapsulation. Which at that point you might as well make the l-value public.

-Alex