Give struct the status it deserves

[Stewart Gordon]

Oskar Linde wrote:
> Stewart Gordon wrote:
>> Hong wrote:
>>> Structs are second class citizens of... or maybe refugees of D, they 
>>> are victims
>>> of discrimination.
>>> Following are the reasons:
> 
> [snip]
> 
>>> 4. structs cannot have constructor, "static opCall" is best you can do.
>>
>> What's wrong with that?  Do you simply miss the word "new" in uses of 
>> static opCall?
> 
> The problem with not having real constructors is that you can not 
> guarantee that your struct gets initialized correctly.

Is the definition of a "real" constructor simply such that one is 
required to use a constructor rather than a static initialiser or 
leaving default initialisers to it?

<snip>
>>> 6. yes, you can use pointers to change a struct member without 
>>> copying, if you can be bothered to define 2 accessor methods, one 
>>> returns a copy another one returns a pointer.
>>
>> Why would anyone want to do that?  What's wrong with simply
>>
>>     Qwert yuiop = asdfg;    // to create a copy
>>     Qwert* zxcvb = &asdfg;  // to create a pointer
> 
> If I understand correctly, Hong is talking about struct members (i.e. a 
> member variable of a struct type), that should be accessed through an 
> accessor method. I.e:
> 
> Array!(Position) points = ...;
> points[5].x = 7;

Note that the OP hasn't mentioned container methods by this point.  It 
therefore appears that this was about properties of the struct itself. 
But looking down, it now appears that it was *meant* to be about containers.

<snip>
>>> 7. Most standard containers (DTL) do not allow a pointer to a 
>>> contained struct to be retrieved, all changes, or just about
>>> anything has to be done via copies.
>> 
>> That's an issue with those containers, rather than with structs 
>> themselves.
> 
> I agree that this is not an issue with structs.  But it is an issue with 
> the language. Given:
> 
> struct Position { int x,y; }
> 
> There is no way to duplicate the behavior of:
> 
> Position[] points = ...;
> points[5].y = 5;
> points[3].x += 2;
> 
> With an user defined container type.

You can if you define opIndex to return a pointer.  But that would 
require you to use a * when it's the value you need.  Or, as was 
suggested, define a separate accessor method that returns a pointer. 
But I see your point now.

>>> Imho, following are little suggestions for structs to make first 
>>> class citizens
>>> of D:
>>>
>>> 1. have some sort of reference semantic to replace pointers. Pointers 
>>> are not
>>> necessary unless structs are used with "new"
>>
>> Maybe you could elaborate on how these reference semantics would work 
>> such that they'd be any different from classes.
> 
> You could consider:
> 
> struct MyPointContainer {
>     Position[] points;
>     inout Position opIndex(uint ix) { return &points[ix]; }
> }
> 
> Where inout denotes that the struct is returned by reference.

Yes, that's a possibility.  Though the & ought not to be there - the 
referencing/dereferencing would be implicit on both sides with inout 
returns, just as it is with out/inout parameters.

And it isn't giving structs reference semantics, it's a way of enabling 
returns from functions to have reference semantics in the same way as 
out/inout function parameters have.  It would work on any type, not just 
structs.

I suppose that, when this is done

     container[42] = something;

would be interpreted by looking first for an opIndexAssign and then for 
an opIndex with inout return.  But how would overload resolution work 
between the two forms?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.