Hi, first of all... +1 then my reply is based on the python experience and syntax.
2015-02-10 17:17 GMT+01:00 Tom Hacohen <[email protected]>: > Hey, > > Daniel and I are back to hacking on Eolian and we've again reached the > topic of nullability. > > In most correct cases, C pointers either point to a valid memory region, > or hold NULL. While NULL is valid for many APIs, it's not valid in > others (strlen() and etc.). > I can think of three examples of NULL in API: > 1. Pointers for multiple return values - size_get(&w, NULL), the second > one is an optional return value. > This api (a property) translate to python as: x, y, w, h = obj.geometry So there are no way to make one of the value optional, I think that @optional is an interesting tag, but you example is not the right one, we need a function, not a property. > 2. NULL is a valid value: part_text_set(NULL, "some text"), the NULL > means "use default". > This is another good example, if I'm not wrong, we hen have text_set("some text") that is a macro around part_text_set. We should avoid using macro (as we discussed yet) to simplify bindings generations. In this case I think we should just have 2 different functions: text_set("some txt") part_text_set("part" @notnull, "some text") > 3. NULL is not allowed: strlen(). > > For 1 we suggest having @optional, which indicates optional values > (similar to what they do in gobject land). > Dunno how gobject manage that, but in python, if we wan to support the @optional tag then all the optionals must be at the end of the params list, example: function(param1, param2, param3 @optional, param4 @optional) is good while: function(param1, param2 @optional, param3, param4) is not really translatable in py... Or at least I dunno how to implement that > For 2 we suggest @nullable, indicating null is a valid value. > And 3 is the default. > No strong opinion on @nullable, only think I can say is that in python/cython we can use "not None" keyword to say that a param cannot be null, not the contrary. So it would be more convenient to have @notnull instead. > > This works great, until you consider that in EFL land, we like using > EINA_ARG_NONNULL(). EINA_ARG_NONNULL() is a macro for decorating > function parameters, and is actually a wrapper around a gcc attribute > "nonnull". This attribute is great because it decorates the parameters > in ways that can help static analysers understand our code and find > error cases, and adds compiler warnings for obvious things (like passing > NULL). However, the problem with this attribute is that according to the > GCC manual: > "The compiler may also choose to make optimizations based on the > knowledge that certain function arguments will not be null."[1] > Which means it's possible it'll remove our runtime checks, which is a > price we are not willing to pay. This essentially means that decorating > our API with this is dangerous and should be avoided. This notion is not > new, this is something we've discussed in the past, and I think now that > we are cleaning the why we define our API, it's time to mention it > again. This attribute is not safe and should be avoided. > Bottom line, I'd like us to stop using EINA_ARG_NONULL, and to inform > you we plan on not using it in generated Eolian headers any more. > > I'm sending this email because I'd like to see what you think about the > suggestion for eolian (@optional and @nullable) and the idea of dropping > EINA_ARG_NONULL given that it's unsafe and can result in removed safety > checks. > > No need to reply with +1, I don't care for votes of support, only > arguments against (and arguments for if arguments against are raised). > We are going to implement @optional and @nullable anyway (can be removed > if someone finds them stupid), so it's mostly about the nonnull part. > > Thanks, > Tom. > > Reference: > [1] https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
