On Sun, Jan 27, 2013 at 03:54:54AM +0100, Adam D. Ruppe wrote:
> It would be cool if we could declare variables with anonymous types;
> 
> struct { opAssign() {} } foo;

I was thinking we could just use a template to alleviate much of the boilerplate of creating a property using a struct. For example, something like:

	struct Property(T, alias setter, alias getter) {
		@property T get() {
			return nullaryFunc!setter();
		}
		alias get this;

		void opAssign(T val) {
			return unaryFunc!setter(val);
		}

		// ... add other standard stuff like opAssignOp, etc.
	}

Then you could use it like this:

	struct S {
		int x, y;
		Property!(int, ()=>x+y, (int z) { y=z-x; }) derivedProp;
	}

The syntax could do with some improvement, though. Maybe an alias:

	struct S {
		alias Property!(int, ()=>x+y, (int z) { y=z-x; }) DerivedProp;

		int x, y;
		DerivedProp derivedProp;
	}
	S s;
	s.derivedProp = 123;
	auto ptr = &s.derivedProp;
	writeln(*ptr);
	// etc.


T

-- 
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, / The day and hour soon are coming / When all the IT folks say "Gosh!" / It isn't from a clever lawsuit / That Windowsland will finally fall, / But thousands writing open source code / Like mice who nibble through a wall. -- The Linux-nationale by Greg Baker

On Friday, 25 January 2013 at 18:03:54 UTC, Rob T wrote:
> On Friday, 25 January 2013 at 17:52:12 UTC, Dmitry Olshansky wrote:
>>>
>>> Instead, we should be trying to continuously expand the things we
>>> guarantee will continue to work. Ideally we would be precise about the
>>> things that are likely to change, and which we don't currently guarantee.
>>
>> +1
>
> I agree with this completely, but we cannot do it until there's a full implementation of a reasonably designed and followed development and release process that includes the language specification.
>
> --rt

+1

The language has reached a point where bugs in the spec are more important than bugs of the implementation. In fact many difficult bugs in the implementation are rooted in spec issues.

On Thursday, 24 January 2013 at 18:38:00 UTC, Adam D. Ruppe wrote:
> Thinking about it, this isn't quite a full circle. It does improve a bit.
>
> If we aren't going dip21, how about:
>
> ===
>
> Everything stays the way it is now, except:
>
> * if a @property is called with parens, they always apply to the return value
>
> * -property hopefully dies.
>
> ===

If this means keeping the writeln = ""; then vote++. I've got no issues
with the property syntax for methods. I actually want them. Why should properties only get the shorter syntax?





>
>
> I don't really like it, it leaves a number of problems behind... but that would be an improvement on the status quo. I don't hate it.
>
>
> So:
>
> alias void delegate() Callable;
>
> Callable nonprop();
> @property Callable prop();
>
> Callable returned = nonprop; // ok, the parens are optional
> Callable returned = nonprop(); // ok, nonprop() just calls nonprop like any other function
>
> Callable returned = prop; // ok, no parens still calls, just like before
> Callable returned = prop(); // NOT GOOD: the () applies to the Callable (which returns void), not prop, because prop has @property
>
> BTW
> nonprop()(); // calls the Callable (this expression returns void)
> prop()(); // nonsense (prop() returns void, which is not callable)
>
> ---
>
> int nonprop();
> @property int prop();
>
> int returned = nonprop; // fine, optional parens
> int returned = nonprop(); // fine
>
> int returned = prop; // fine, we just call prop
> int returned = prop(); // NO GOOD: the () always applies to the return value, which in this case is int, which is not callable

On Sunday, 27 January 2013 at 09:51:04 UTC, SomeDude wrote:
> On Friday, 25 January 2013 at 18:03:54 UTC, Rob T wrote:
>> On Friday, 25 January 2013 at 17:52:12 UTC, Dmitry Olshansky wrote:
>>>>
>>>> Instead, we should be trying to continuously expand the things we
>>>> guarantee will continue to work. Ideally we would be precise about the
>>>> things that are likely to change, and which we don't currently guarantee.
>>>
>>> +1
>>
>> I agree with this completely, but we cannot do it until there's a full implementation of a reasonably designed and followed development and release process that includes the language specification.
>>
>> --rt
>
> +1
>
> The language has reached a point where bugs in the spec are more important than bugs of the implementation. In fact many difficult bugs in the implementation are rooted in spec issues.

I went to stress the "followed" part. I.e. we do have quite a good release process description on wiki with some related parts also mentioned. But if it is followed as good as upon 2.061, it makes not difference.

On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>
> I hate optional parentheses with a passion
>
> - Jonathan M Davis

Same here.

On Sunday, 27 January 2013 at 10:30:41 UTC, sclytrack wrote:
> On Thursday, 24 January 2013 at 18:38:00 UTC, Adam D. Ruppe wrote:
>> Thinking about it, this isn't quite a full circle. It does improve a bit.
>>
>> If we aren't going dip21, how about:
>>
>> ===
>>
>> Everything stays the way it is now, except:
>>
>> * if a @property is called with parens, they always apply to the return value
>>
>> * -property hopefully dies.
>>
>> ===
>
> If this means keeping the writeln = ""; then vote++. I've got no issues
> with the property syntax for methods. I actually want them. Why should properties only get the shorter syntax?
>
>
>

Also since you can't overload @property opDispatch and opDispatch at the same
time without knowing all the property names or method names at compile time you
can use the opDispatch for everything if the methods have a property like syntax.

On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>>
>> I hate optional parentheses with a passion
>>
>> - Jonathan M Davis
>
> Same here.

In Delphi they are also optional and nobody uses them. However, everybody else doesn't use them.




:-)

int CoolThing { in; out; } - auto property without implementation;

int CoolThing { private in; out; } - private setter; public getter;

int CoolThing
{
   in
   {
      _privateCoolThing = @value * 42;
   }

   out
   {
      return 42;
   }
}

Explicit calling: void in_CoolThing(int); int out_CoolThing(); Proper "Property rewrite" can be implemented.

Property CoolThing looks like code contract for _privateCoolThing. So it's maybe + or -.

At all, it looks like C# style in D Way.

--no-parenthesis for current behaviour for non-property functions.

On Sunday, 27 January 2013 at 11:18:01 UTC, sclytrack wrote:
> On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
>> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>>>
>>> I hate optional parentheses with a passion
>>>
>>> - Jonathan M Davis
>>
>> Same here.
>
> In Delphi they are also optional and nobody uses them. However, everybody else doesn't use them.
>

Delphi has no real functional capabilities.

On 01/27/13 03:48, Rob T wrote:
> On Sunday, 27 January 2013 at 01:11:05 UTC, H. S. Teoh wrote:
>> On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
>>> We can almost implement properties as a regular struct
>> [...]
>>
>> You do it like this:
>>
>>     import std.stdio;
>>
>>     struct IntProp {
>>         int __impl;
>>
>>         @property /* <-- ah, the irony! */ int value() {
>>             return __impl + 123;
>>         }
>>         alias value this;    // watch this magic
>>
>>         void opAssign(int val) {
>>             __impl = val - 123;
>>         }
>>     }
>>
>>     struct S {
>>         IntProp prop;
>>     }
>>
>>     void main() {
>>         S s;
>>         writeln(s.prop);
>>         s.prop = 321;
>>         writeln(s.prop);
>>     }
>>
>>
>> T
> 
> Ah cool! You don't really need @property however if we adopt the optional () unless that's to be enforced.
> 
> The really nice thing about this, is we can return the struct as a ref, and it still works, and also take the address of the struct and it continues to work.
> 
> Even better I can add more member functions to it and expand on what it can do. The "property as a function" approach is far more limiting and has issues, such as ref returns and taking the address.
> 
> Anyone know what's missing or what won't work with this approach?

   auto w = Widget();
   w.width = 3;
   w.height = 14;
   auto a = w.area;

Consider an implementation of Widget where some/all of these fields are properties.

Also, does adding a "virtual" area property (ie one calculated on demand from the others) influence the layout of the object? Should it?

IOW, there are many problems with such a solution, some of which can be worked around, others fixed with relatively small language changes (legalizing zero-sized objects, making a static-outer implementation cleanly doable etc).

But would there really be enough gain to justify making properties that much more complicated? The present approach is a reasonable compromise, it just needs proper call handling.

Consider the case, that is some times brought up here, where you use a library
which at some point is changed and some object fields are replaced by properties.
You recompile your code with that newer version. What keeps working? What breaks?
Which breakages can be avoided? Which ones would you really want to examine and
handle manually?
Any field->property change breaks the ABI, but this can only be avoided by
preemptively using accessors. That doesn't affect @property as such, except that
having some kind of syntax sugar would make creating the required forwarders easier.

Handling @property evaluation correctly not only makes sense, it's necessary to make
them work correctly. But further "improvements" bring few extra benefits, while
complicating the language. Parens-less function calls are a much bigger problem;
I can't see much gain from "cleaning up" the property design.

While killing @property /is/ an option, it's not a good one either, especially if ()-enforcement on all calls doesn't happen before such a change.

artur