As far as I can see from struct_definition.hh, fields are intentionally read-only (don't know the reason, tho), while properties may be writable. Should we change that rule and add a set for them, then? Where could I find the reasoning about who should be read-only, etc.?

Oops, just realized actually structs don't have properties (https://www.enlightenment.org/contrib/docs/eo). Maybe changing an eo-struct would require creating a new one with modified values, letting mutability only to classes?

I don't know why that was done that way, but seems a bit arbitrary to me. Maybe @felipealmeida knows?

I think this is just someone missing the setter. The setter should exist IMO. @jptiz can you look at this monday? Thanks.

@felipealmeida So, I've found rEFL581bec9598943cc9274dfe7db1a73a4c878c3cdd, which makes struct immutable because of C# recommendations (and there's the reasoning I was looking for, too). Should we propose to make EO structs generate classes instead, then? Where could I read/who to talk about if it would or not go against the idea of EO structs?

@jptiz No. Leave it as is then. @segfaultxavi do you agree with the patch reasoning?

If C# devs are not used to mutable structs, then we should not provide them, yeah.
What do you suggest we do, though? EO structs ARE mutable.

IMO Eo structs are not mutable per se. C and C++ structs are mutable.

So how's the user of a EO struct supposed to put the information inside it?

@q66 @zmike @bu5hm4n any opinion on this?

Just to add some (possibly) useful info:

1. There was some previous discussion about this in #efl# IRC Channel regarding the default behaviour: since EO is (sort of) a binding generator, maybe it doesn't have to define things such as mutability per se. It would just translate to the desired language's features - then the discussion would become "what are the appropriate features?".

2. If we agree with 1., what would make more sense?
   • Option 1: Translate Eo structs to C# classes, copying mutable behaviour from C structs (altough enforcing heap allocation instead of a possible alloc. in stack);
   • Option 2 (current): Translate straight-forwardly into C# structs (as it is now), but that would mean they would be immutable in the C# side, so the programmer would be on his own to deal with it (e.g. creating a new instance based on the original - see below).

For Option 2, then a workaround for @segfaultxavi's case (Size2D.W set) would be like the following:

void Foo(Bar something) { // assuming `Bar` is a class and `something.Size` exists
    ...
    // eventually having to double something's size:
    something.Size = new Size2D {
        W = something.Size.W * 2,
        H = something.Size.H,
    };
    ...
}

Which would still be idiomatic, just would need some more work/considerations from the programmer's side.

3. As for current usage, as far I as searched, every usage of Eo-structs seems to be in contexts that would be fair to be immutable (*Args for event callbacks, for example).

I understand the C# reasoning. But I still think being able to write size = new Size2D(w,h); but not size.W = w; is extremely weird.
However, I am not a C# person. Maybe we need also input from the C# users? @woohyun @YOhoho ?