slint icon indicating copy to clipboard operation
slint copied to clipboard

Enums in .slint

Open ogoffart opened this issue 3 years ago • 4 comments

We should have a way to declare enums in .slint.

enum Foo { bar, bli, bla, blu }

The question is wether to have a := for consistency with struct. An option is also to remove the := for structs.

ogoffart avatar Feb 01 '21 08:02 ogoffart

Currently, all our built-in enums values are kebab-case. The rational for that is that this is closer to CSS syntax.

When we will be able to declare enum values in slint, we will generate Rust or C++ enum. But in Rust the convention is to use CamelCase enum values.

Should we keep the convention of lower case enum values for enums declared in .slint files by users?

Should we somehow enforce this convention with warning like rust do?

Should we convert to CamelCase enum values while generating rust code? Or should we make it configurable somehow?

For the builtin enums, they are currently not part of our public API, but maybe they would become part of it. Should we change them to be CamelCase in rust and C++?

ogoffart avatar Jul 21 '22 16:07 ogoffart

Should we somehow enforce this convention with warning like rust do?

I'm torn about this, but I'd say no. I think we should produce warnings about behavioural, performance or type incompatibility related issues, but not about style.

Should we convert to CamelCase enum values while generating rust code?

Could this be done in an automated way? I can't think of how. In the absence of a reliable automated way:

Should we keep the convention of lower case enum values for enums declared in .slint files by users?

I'm leaning towards going camel case for enums all the way. That way we loose consistency with css but we gain consistency with Slint, C++, JavaScript, Rust, etc.

Or should we make it configurable somehow?

I'm not in favour of making this configurable. I can't think of any other transpiler or code generator that configures this, beyond say cbindgen (but that's niche :)

For the builtin enums, they are currently not part of our public API, but maybe they would become part of it. Should we change them to be CamelCase in rust and C++?

I'm in favor of that, yes.

tronical avatar Jul 22 '22 06:07 tronical

Should we convert to CamelCase enum values while generating rust code?

Could this be done in an automated way? I can't think of how.

Yes we can of course. The compiler can do that, and already does for some internal accessibility enum: https://github.com/slint-ui/slint/blob/ee18236053c6073fedd2497bbd904c4541100880/internal/compiler/llr/lower_to_item_tree.rs#L287

For the builtin enums, they are currently not part of our public API, but maybe they would become part of it. Should we change them to be CamelCase in rust and C++?

I'm in favor of that, yes.

I'll make that change then. Edit: https://github.com/slint-ui/slint/pull/1418

ogoffart avatar Jul 22 '22 06:07 ogoffart

Ah yes, thanks for the reminder. Somehow I thought the types are randomcamecase but we have separators between them :)

tronical avatar Jul 22 '22 06:07 tronical