In T8620#150911, @bu5hm4n wrote:

Maybe try to build efl with asan enabled, maybe that is causing it to crash ? (meson configure -Db_sanitize=address)

In T8620#150908, @zmike wrote:

Probably want to valgrind that, the errors printed here aren't related.

You mean this?

True, my EFL was out of date!

Oh, okay, found the neovim issue: the file is actually called "nvim.desktop", not "neovim.desktop", that's why. My eyes just didn't catch it at first.

About the purpose: understood, gonna update the main post.

Add a test-case.

Add tests.

Add tests.

Just to add some (possibly) useful info:

Got the following build error for efl_mono.dll:

Passes tests and has pretty nice refactors.

Fix mess with arc: considering only last commit, not the entire dependencies.

Add managed name to exception message and simplify ifs.

Indexers have been reverted as not good practices for our use-cases (as stated in D11114).

@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?

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?

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.?

Does this commit resolve this task? Or is there something missing?

Looks good to me :)

Updated diff title to describe better what does it change.

Update to reflect changes from 581bec9598943cc9274dfe7db1a73a4c878c3cdd.

In D11190#212430, @segfaultxavi wrote:

The accessor<string> part is generating invalid C# code:

src/bindings/mono/efl_ui_dnd.eo.cs(438,69): error CS0029: Cannot implicitly convert type `System.Collections.Generic.IEnumerable<string>' to `System.IntPtr'
src/bindings/mono/efl_ui_dnd.eo.cs(448,69): error CS0029: Cannot implicitly convert type `System.IntPtr' to `System.Collections.Generic.IEnumerable<string>'

As far as I can see, this is the first time we try to use this in our API.
Calling in the C# people... @felipealmeida, @jptiz, any idea what is happening?

Use current indent level instead of arbitrary level 2.

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

Reopen Diff and add "ItemX" for each item (where X is the item's index within the tuple).

In D10889#205035, @segfaultxavi wrote:

Cool! Renders nicely with DocFX.

Removed whitespace changes.

Looks like we should not be using tuples as return values after all. It is recommended to use a explicit class, with proper fields and docs.

csharp: Add 'since' documentation to deconstruct.

Fix wrong generate_deconstruct_method return (shouldn't be negated).

Add "Depends on D10801."

Switch unused struct_.fields to attributes::unused.

In D10809#204222, @lauromoura wrote:

Shouldn't this be applied on top of D10801? It fails with a conflict in the struct_definition.hh blocks.

Squash commits into just one.

• csharp: Fix missing comparison in test.

• csharp: Fix test for complex struct packing.

Just fix lines eina_error.cs:{158,174} and eldbus_common.cs:1554: "an event" (since "e" is a vowel sound - check here).

I've got the following compilation error:

Add tests and remove implicit conversion for 1-field structs.

Going to add some tests.

I was working on this task, but then I ran into a problem with generating tuples for structs with too many fields. More specifically, after generating: