3f083b3ccba9cdc0f9cfe875fec030e228be69d0

you still missed one

You can't just eina_hash_add into nhash without checking !oobj because if you do and the entry is already present, that's undefined behavior for our hash implementation, so either keep the if or make them eina_hash_set

That works too

I intend to do away with const() as well as ptr() in the current form entirely, so having a new syntax is the better choice for it, besides, immutable by default is a better choice than mutable by default

Or maybe, make them const by default and some kind of event tag to make it mutable where needed?

Understood. Do we need a way to make objects const when possible?

That sounds good to me. So basically the only types allowed are value types, objects and container types, minus list/iterator; everything is annotated without any qualifier, and everything is immutable and passed by reference, except objects. Maybe we should pass objects by const too? So that only @const methods can be called on it. That would make all event data completely immutable.

I'd say that allowing less is always a good thing, as it allows for fewer errors/mistakes, so if we can do away with it, let's do it

I don't think we currently specify how things are *meant* to be; we need to come up with something.

Any proposals on this?

rebase + remove leftover macro usage

The comment in elm_interface_scrollable.c is fine, doesn't need changing.

Looks like this one is good to go https://travis-ci.org/Enlightenment/efl/builds/506793582

rebase + more fixes

Yeah, I'm ok with not having vars, as the abuse potential is there. Constants are another matter, these are constrained and rather trivial.

I decided it's for the best to solve this properly at a later point

marked missing classes beta, rebase

We can not, these are a workaround for beta API enabled but do API disabled, eo files still depend on those, we need to solve this properly later but that will take more effort than is reasonable right now

rebase

rebase

previously they weren't assumed anything, any checks regarding beta were simply skipped, but @beta could be used the same; the new behavior checks them, so i only fixed those classes that were newly causing errors

removed outdated comment

rebase

rebase

can't enable beta guards for types yet, as it triggers too much
brokenness which we can't fix in time

rebase

added support for marking function types beta

added generator support, fixed parser bug, rebase

There is also nothing wrong with the test results of your test, that is fully intended; the class is not in the Efl. namespace, therefore it's not treated as a stable class. Putting it in the Efl. namespace makes it warn normally:

Struct fields are checked implicitly by design just like all other types, it does not need any specific code. When a non-beta function/typedecl/whatever is encountered, the validator switches state into "stable" mode and any dependent types (which includes anything in struct fields) are required to be non-beta. I will investigate the other stuff.

I'll take src/lib/elementary/elm_*.eo.

I know this changes Eolian API so since we're in a freeze it's probably not 100% ideal to merge this, but we need this to be able to stabilize at least something at all.

We have no Elm_Win_Type in eo files, nor Eolian provides any facilities to deal with legacy types, so this will need to be fixed manually as manual legacy APIs are pushed into the tree.

Removed in 4b1622b5fc7c6aaafb4d70f187ec5ea797275a26

bf4280e915ebbd4cbad2ee9c8fcd2730fd29eb6f

will be re-implemented correctly from scratch next release

will be re-implemented correctly from scratch next release

4b1622b5fc7c6aaafb4d70f187ec5ea797275a26

This seems fine to me, but I need @felipealmeida to confirm whether it's fine to remove inlist/inarray from Eolian itself for the time being. The reasoning is that there are no users of it in our API right now, and it will take some more time to get it right, so it's best to leave it for next release.

no punctuation in error msgs please

Other than what @bu5hm4n pointed out, looks fine to me. So fix that and then @bu5hm4n can accept the rev and we can land it.

Added support for iterative freeing of fields in inarray structs, though still not sure whether to keep it.

I added a bunch of stuff in my branch: https://git.enlightenment.org/core/efl.git/log/?h=devs/q66/eolian-inlist-inarray

Check here: https://git.enlightenment.org/core/efl.git/commit/?h=devs/q66/eolian-inlist-inarray&id=a9917a0c0fe96e5260d571dbc928e80d66fbd567

Check here: https://git.enlightenment.org/core/efl.git/commit/?h=devs/q66/eolian-inlist-inarray&id=a9917a0c0fe96e5260d571dbc928e80d66fbd567

The thing in charge of freeing the structure is in charge of freeing its owned fields. If they're not marked owned, it is assumed that the struct does not own them and they will be freed somewhere else. I wonder if this behavior is what we want though. Maybe we should make them owned by default, and reverse the behavior so that you explicitly have to mark the field *not* owned in order to prevent it from being freed as a part of the structure?

Yes, we allow that. It means the struct owns the reference. If the field is not @owned, it will not be freed when freeing the structure. It is separate from owning on params; if the param is not owned, it means the caller will free it, if it is, it means the callee will free it. Either way, @owned fields will be freed by one of them.

you forgot an else