Possible @property compromise

Steven Schveighoffer schveiguy at yahoo.com
Thu Jan 31 14:54:21 PST 2013


On Thu, 31 Jan 2013 17:11:28 -0500, Zach the Mystic  
<reachBUTMINUSTHISzach at googlymail.com> wrote:

> Thanks for looking at it.
>
> I only read the C# documentation for properties briefly, but I didn't  
> find my suggestion to be a duplicate of them. In particular, can C#  
> properties do anything more than just get and set? My suggestion allows  
> harnessing the full power of D struct semantics. Is this not a far more  
> expansive solution than what C# has?

C# has properties like this:

property int foo {
   get {return _foo;}
   set {_foo = value;}
}

Your proposal looks like this:

foo struct {
    int opGet() {return _foo;}
    void opSet(int value) {_foo = value;}
}

What I see is that the getter and setter are assigned specific contextual  
keywords (opGet vs. get, and opSet vs. set). It seems like a very similar  
(albeit more verbose) solution.

What I had originally suggested for properties is this:

property int foo {
    int get() {return _foo;} // only one getter allowed
    void set(int v) {_foo = v;}
    void set(float v) {_foo = (int)v;} // more than one setter allowed
}

I think these are all along the same line of solutions.  I don't think  
they are bad, but clearly they weren't used 4 years ago, so it may be  
difficult to convince Walter to use them now.

> My opGet is just another opXXX definable for all structs, not just  
> properties.

I didn't see that, but I also don't really see the point of that.  What  
value does opGet have unless it's a getter for a property?

> I had said it was necessary to achieve structs as properties, but I  
> think I was wrong. It's just the equivalent of:
>
> int __someRandomFunction() { return _propValue; }
> alias __someRandomFunction this;
>
> But it would be syntactically nicer, much like Highlander structs are  
> syntactically nicer. Therefore, the only language change absolutely  
> required would be making non-static structs nested in structs behave  
> like non-static structs nested in functions, which they arguably should  
> do anyway. Also under the hood, some important optimizations getting rid  
> of pointers for data-less structs.

This is a VERY bad idea.  A struct is POD.  For example, consider a range  
type for a container.  You may not NEED to have a pointer to the  
container, so that is wasted bytes.

Also note that structs are not meant to have internal pointers.  So a  
"property" struct with an internal pointer

The strange case for a struct type inside a function kind of makes sense,  
because of the ability to access the function's variables, and because you  
can't really move the stack frame.

-Steve


More information about the Digitalmars-d mailing list