Possible @property compromise

[Steven Schveighoffer]

On Fri, 01 Feb 2013 14:17:00 -0500, Zach the Mystic  
<reachBUTMINUSTHISzach at googlymail.com> wrote:

> On Friday, 1 February 2013 at 18:34:01 UTC, Steven Schveighoffer wrote:
>> I think you are wrong in how you assume a struct works, but not in your  
>> attempt to implement properties.  Struct is just not a key to this  
>> formula.
>
> I disagree. It is absolutely the fundamental key to this formula.

Well, we can disagree, but you still haven't explained why it's  
fundamental.  Other languages have implemented properties just fine  
without having to specify that they are structs or aggregate types.  Until  
you come up with a compelling reason for structs, I'll stand by my  
position.

>> Note that many (including myself) consider the overloading of static to  
>> be a *detriment*.
>
> I guess there's certainly a matter of taste involved here. Had you  
> suggested another keyword, or what had your preferred suggested syntax  
> looked like?

@property.  It's already there, already used for properties.

@property foo {

    int get(); // or opGet
    void set(int val); // or opSet

    opBinary(...)  // etc.
}

> I'm sorry we couldn't find common ground here. I can imagine two camps  
> developing, one with your ideas and one with mine. As far as a static  
> struct function, how could it get the pointer to its enclosing struct,  
> which it needs in order operate on the enclosing struct's data?

There is NO difference between a static struct function and a normal  
module-level function, EXCEPT in the namespace.  How could it get the  
pointer to its enclosing struct?  It can't.  Because a struct TYPE doesn't  
HAVE an enclosing struct.  It could have an enclosing struct TYPE, but  
that's it.  In order to have an instance pointer, it needs to have an  
instance, and you need to have a non-static struct function.

Now, you are proposing that we have these special structs (nested structs)  
must be labeled static, but are not actually static (their methods require  
a context pointer), who can never have any fields, and whose methods  
accept a this pointer is not the pointer to the struct instance, but the  
instance of the containing type (be it class or struct) they reside in.   
To say this is "just another struct" is an extremely large stretch.

I don't want to come across as mean or condescending, but what you have  
described could never be considered a struct.  Period.  If you insist that  
struct is to be used, you will be bashing your head against a brick wall  
forever here.  Drop the idea that it must be a struct, and you may gain  
some traction.  I'm not saying this because it's my opinion, I'm saying  
this to prevent you from wasting any more time.

I don't really want to waste any more of my time either, if struct is what  
you insist on, then I will respectfully bow out of the conversation.

-Steve