On 24 apr 2011, at 18:03, Robert Jacques wrote: > On Sun, 24 Apr 2011 07:33:30 -0400, Jacob Carlborg <[email protected]> wrote: >> On 23 apr 2011, at 23:20, Robert Jacques wrote: >>> On Sat, 23 Apr 2011 16:06:35 -0400, Jacob Carlborg <[email protected]> wrote: >>>> On 23 apr 2011, at 17:32, David Simcha wrote: >>>>> On 4/23/2011 11:24 AM, Jacob Carlborg wrote: >>>>>> I think I would like to have something in the middle of strict and loose >>>>>> semantics. I would like that functions marked with @property have to be >>>>>> called like a field: >>>>>> >>>>>> auto bar = foo.field; >>>>>> foo.field = 3; >>>>>> >>>>>> But functions not marked with @property still can be called without the >>>>>> parentheses: >>>>>> >>>>>> foo.bar(); >>>>>> foo.bar; >>>>> >>>>> Maybe there's been some misunderstanding, but actually this is what loose >>>>> semantics means. Loose semantics (at least as I understand them) mean >>>>> stuff marked @property would not be callable using method syntax, and >>>>> this rule would be used to disambiguate the corner cases, but nothing >>>>> would change for stuff not marked @property. >>>> >>>> Ok, then I probably misunderstood. What about: >>>> >>>> writeln = "foo"; >>>> >>>> is that already fixed? >>> >>> If by fixed, you mean doesn't compile, then yes, it's fixed. But this might >>> be a quality of implementation issue, regarding method syntax and templates >>> and not a true theoretical fix. Case in point: printf = "foo" works. >>> However, while ugly, neither writeln = "foo" nor printf = "foo" are doing >>> something the original author didn't intend. The greater violators (which >>> actually caused bug reports/confusion) are those where the statements >>> became nonsense, like math_function = 5 or obj.factory_method = 6.[1] Fixes >>> for most of these issues exist: Not using the result from a strongly pure >>> function should be an error, not matter how it's called. And >>> const/immutable methods shouldn't be assignable, since you can't assign to >>> a const or immutable variable. Static/free functions can't be marked >>> const/immutable, but considering the only thing they can modify is global >>> state, pure is equivalent. So neither strongly nor weakly pure functions >>> should be assignable. >> >> If writeln = "foo"; doesn't compile but printf = "foo"; does then I would >> consider it not fixed. The way I would want @property to behave is disallow >> bar = "foo"; for functions not marked with @property. But still allow >> functions not marked with @property to be callable without parentheses. > > I have not heard this particular combination before; thank you. More choices > are always appreciated. There are real, practical use cases for not-@property > methods with write-only field semantics, which this would prevent. And > between a real use case and a synthetic straw-man, I believe the use case > should win. However, I am interested in any of the practical issues which > inspired writeln = "foo", if you know of any.
I don't know if there is an issue with writeln = "foo" other than that it can be confusing and looks very odd. > Also, this and another post have given me an idea: what if non-@property > methods could be assigned to if and only if a valid 'getter' also existed. > This would still 'fix' writeln = "foo" but be a less restrictive than an > outright ban. Hm, it sounds like a strange rule, I don't know, it could work. > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos -- /Jacob Carlborg _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
