On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
Right, ideally a @proptery function can perfectly replace a variable, but practically calling the return value seems far fetched. What would you use that for, a handwritten interface struct with function pointers made read-only using @property?



It doesn't matter. If you want an explosion of special cases, there is already a language for that, it is called C++.

Every time an exception is introduced, the "burden of proof" is to prove this exception actually bring sufficient value to pay for itself, not the other way around.

To me the whole property discussion looks like one of those endless debates about an insignificant detail.
Scala and Ruby seem to do well with sloppy parens.

For what I've touched of ruby, the language is very permissive and nice. This is good when you do your first prototype, but this is also what causes it to be intractable at scale (and also impossible to optimize, but that is beside the point here).

Is the parentheses thing a problem ? Not really on its own, but it compound.

The parentheses thing and with it the special _ syntax to NOT call a function is not considered as a good thing by most scala people I've talked to.

With the introduction of UFCS it became clear that nobody likes byLine().array().sort().release(), and even less rng.release.sort().array().front. For some functions it's really hard to decide whether or not something is a property, e.g. for me Range.save is an action/function not a property. So for me using @property appears to waste time making pointless decisions.

One can reach the desired effect by having a consistent set of rules and define the calling as a fallback rewrite when there is an error. Namely, add a rule that says : if this is an error, add () and retry. Here you go, problem solved, you can use parentheses function call in every places it is not ambiguous without introducing Byzantines set of rules into the language.

Reply via email to