@property fields

[Jonathan M Davis]

On Thursday, December 5, 2024 6:48:44 PM MST Richard (Rikki) Andrew Cattermole 
via dip.ideas wrote:
> Just to be clear, as far as I'm concerned, either this gets fully
> designed and implemented or it should be removed.
>
> We can't keep things like this in the language where its not doing
> anything useful for people (yes I know it does one thing that could be
> replaced with a trait).
>
> So if you have a proposal on how to make it worth keeping, please
> propose it. Otherwise I'm going to have to assume such push back is in
> favor of removal.

IMHO, what should be done with @property is what SDC does, which is make it
an error to use the property like a function, which would allow us to have
@property functions which return delegates and other callables. That's what
originally was going to be done with it (along with making it illegal to
call non- at property functions without parens), but since UFCS made it
unacceptable to require that functions be called with parens (since many
folks don't like having the parens with UFCS), we didn't do either even
though we can still do the first part and require that @property functions
not use parens - particularly since that would fix an ambiguity problem that
we currently have with @property and parens.

Either way, if it's a question of having @property variables vs removal, I'd
favor removal, because I don't see much value in the idea of @property
variables.

But it's also the case that if we lost @property, we'd have some problems
with trait-related stuff, since there are cases where we take advantage of
@property's quirk of making the return type be the type given with is
expressions in order to implement traits. Getting rid of @property would
actually break druntime and Phobos as things stand.

- Jonathan M Davis