On Thu, 31 Jan 2013 17:11:28 -0500, Zach the Mystic
<[email protected]> 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
