November 18

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

>

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

>

On Thursday, 18 November 2021 at 04:24:56 UTC, rumbu wrote:

> >
  • struct inheritance

Inheritance (subtyping) and value types don't mix.

A struct can inherit 2 things:

  • another struct
  • an interface

This doesn't involve boxing for structs, just the compiler generating a templated function when encounters the interface as a parametter. At least this is how it is done in BeefLang.

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.

> > >
  • properties

What's missing?

A better syntax? Compiler generated backing fields? The fact they are not working as advertised?

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; }.

> > >
  • pattern matching on fields/properties

How would this work?

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?

November 18

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

> >
  • properties

What's missing?

Ahem...

>

WARNING: The definition and usefulness of property functions is being reviewed, and the implementation is currently incomplete. Using property functions is not recommended...

November 18

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

>

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

> >
  • properties

What's missing?

Ahem...

>

WARNING: The definition and usefulness of property functions is being reviewed, and the implementation is currently incomplete. Using property functions is not recommended...

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

November 19

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

>

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

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

November 19

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

>

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

>

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

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

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.

November 19

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

>

prop += 5;

is automatically lowered to

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

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?

November 19

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

>

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

>

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

>

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

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

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!!!

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.

>

ref prop() { ... } is a very bad anti-pattern.

Why is it bad?

Best regards,
Alexandru.

November 19

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

>

Why is it bad?

Best regards,
Alexandru.

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

-Alex

November 19
On 19.11.21 16:39, 12345swordy wrote:
> On Friday, 19 November 2021 at 14:30:39 UTC, Alexandru Ermicioi wrote:
>>
>> Why is it bad?
>>
>> Best regards,
>> Alexandru.
> 
> It violate encapsulation. Which at that point you might as well make the l-value public.
> 
> -Alex

This is just one way to make an lvalue public. Note that the address might not be constant/at a constant offset.
November 19
On 19.11.21 16:50, Timon Gehr wrote:
> On 19.11.21 16:39, 12345swordy wrote:
>> On Friday, 19 November 2021 at 14:30:39 UTC, Alexandru Ermicioi wrote:
>>>
>>> Why is it bad?
>>>
>>> Best regards,
>>> Alexandru.
>>
>> It violate encapsulation. Which at that point you might as well make the l-value public.
>>
>> -Alex
> 
> This is just one way to make an lvalue public. Note that the address might not be constant/at a constant offset.

(Also, there might be lifetime tracking of some sort going on.)
2 3 4 5 6 7 8 9 10 11 12 13 14