Cannot compile betterC app in windows using stderr

[Steven Schveighoffer]

On 2/3/22 11:13 PM, Tejas wrote:
> On Friday, 4 February 2022 at 00:54:50 UTC, Steven Schveighoffer wrote:
>> Ugh, yep. Damn us for not correctly implementing @property.
>>
>> Would be the same problem with a template as well.
>>
> 
> What will it take to implement `@property` correctly? What is it that 
> we're lacking?

What @property *should* have done (it's very limited in functionality 
now, and not likely to be fixed) is to disable accessing via the 
function at all. The fact that it's a function call should be an 
implementation detail.

in other words:

```d
int _x;
@property ref int x() { return _x;}


static assert(is(typeof(x) == int)); // this is true today
static assert(typeof(&x) == int *)); // this is not true but should be

auto y = x(); // should not compile, but does, an int is not a function.
```

If this were the case, then fixing the stderr problem mentioned here 
would be possible using properties.

> I genuinely don't understand anything about this particular topic: what 
> is preventing us from fixing this particular part of the language even 
> though it crops up pretty frequently?
> Could you maybe please link me to a forum post where this has been 
> discussed?

The @property debate is really old. When it was added, the thought was 
to get rid of some of these sticky corner cases. D has had property 
*syntax* since D1. But the @property attribute was supposed to be a way 
to declare "this is a property, so it shouldn't behave like a function".

But core members disliked the added complications, and so the benefits 
of @property were kind of cancelled. There are a few draft DIPS on it 
(from the old system in the wiki, see here: 
https://wiki.dlang.org/DIPs). Now we are just left with a really obscure 
difference (the typeof difference) which is IMO confusing anyway.

-Steve