Looking good to me

https://phab.enlightenment.org/T7955

Any update on this? Can it be closed? As far as Eolian is concerned it's been done for a while

This has been done for a while.

No, it's not intended, but all you need to do is simply remove the first is_enum check and leave the second one where it is.

The goto is unnecessary, syntax error means a long jump

that helps, i'll add guards for it once I am back

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 eo 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