Mark native properties (typed as plain fields) as having side-effectful reads.

[back2dos]

On platforms that support native properties, getters may cause side effects, but because we type it as default access, the compiler may choose to eliminate them.

The most prominent case I can think of is the DOM API, where it's common practice to query layout properties to cause a DOM reflow. I would suggested @:pure(false) to be in line with methods, but anything else will do just fine ;)

[Simn]

Is this a matter of adding @:pure(false) to externs or do we have to support something in the compiler first?

Either way, we should address this for 4.0 because it has the potential to cause regressions.

[back2dos]

Well, it seems like the compiler is very unimpressed with @:pure(false) on fields. FWIW though, it's not a regression.

[RealyUniqueName]

Is it only applicable to extern classes? Is possible to somehow define such properties in non-extern classes?

[nadako]

I mean you can of course hack in some craziness, but in general Haxe fields are just fields :)

[back2dos]

Well, I do actually have a use case for non-extern classes, but today I don't feel like reopening the old debates on what you should and shouldn't do with properties ;)

My primary concern is that idiomatic code for DOM APIs has its behavior broken through optimization. People can of course just learn that, but if removing this hurdle is easy enough, I would much prefer to just do it.

[nadako]

Yeah I agree about DOM stuff and I can imagine some interesting use-cases with actual Haxe properties, but I was talking about plain Haxe non-extern fields.