Property discussion wrap-up

[Zach the Mystic]

On Sunday, 27 January 2013 at 21:03:45 UTC, Maxim Fomin wrote:
>> int foo() { return 4; }
>> auto x = foo; // Error: gives 4 or gives function foo?
>
> Unlike C, in D a function is not implicitly converted to 
> pointer to function, and because you cannot create functions as 
> stack variables, that statement should fetch 4.

Okay, I was ignorant of that, and it's a bad example. I'm not 
going to pretend I know everything. But the man issue is to make 
ambiguous cases an error and not silently accepted as one or the 
other. If there aren't very many, or even any, then great, it's a 
non-issue.

Thank you for educating me. Also, I thought that cast(function) 
or cast(delegate) was a clear way of indicating the function, 
perhaps just a shorthand for &foo or something, but much clearer.

>> With regard to @property, Rob T suggested that properties are 
>> similar to structs, and Adam D. Ruppe suggested a struct might 
>> be definable as a single instance:
>>
>> struct { ... } foo;
>
> If you mean he suggests to implement properties through 
> structs, than that is discussable,

Yes.

> but if you mean that properties are like structs, than I found 
> it is a bad idea, because structs and properties share almost 
> nothing. Struct is an aggregate of objects of different types 
> with methods and property is an abstraction over particular 
> object which should not be accessed directly but through some 
> procedure.

I may not even know enough to disagree intelligently, but I do 
disagree with what you say here. I believe structs and properties 
have a _lot_ in common. Particularly, they are a namespace, which 
therefore give you the identifier you need to act as if it's real 
data. They also can overload all important operators so that that 
name can lurk amongst ordinary code transparently, as is required 
of properties.

>> struct gogo
>> {
>>  int _foo;
>>
>>  // Note the switched tokens: means foo is the unique instance 
>> of the struct
>>  foo struct
>>  {
>>    int opGet() { return _foo; } // Enforces no parentheses
>>    int opCall() {} // Error: a struct may not have both opCall 
>> and opGet
>>  }
>> }
>>
>
> So, solution is to use some unusual struct type as a wrapper on 
> a member type. Why not default directly to real type like:
>
> // in/out were suggested as D naming for getter and setter in 
> the recent thread
> struct S
> {
>     int foo
>     {
>         in { return ... } // or @set
>         out { ...} // or @get
>     }
> }
>
> Such sort of proposal introduces (like property-struct) 
> significant change to syntax, so why not use fully the 
> opportunity to make the syntax nicer?

You're right, opGet and opSet are as ugly as all the opXXXXX 
overloads. They are nonetheless consistent with how operators are 
already defined, which argues in favor of them. However, "in" and 
"out" above seem out of place too. I don't have a way to make 
opGet, opSet look good, but "in" and "out" in the above example 
are very hard for me to understand, given prior uses of in and 
out.

Also note that opGet and opSet are unnecessary, that structs can 
be made to work in a variety of ways. They can store some data or 
not, act like properties or not, extremely flexibly. 
Single-instance structs just make structs easier to use in 
general.