Allow building `ShaderDefValue` from a string key alone

[djeedai]

It's fairly common to use in shaders a simple boolean flag #if XXX to activate a feature, without caring much about its value. Currently it's rather verbose because there's no existing conversion, e.g.:

let mut shader_defs = std::collections::HashMap::<String, ShaderDefValue>::new();
shader_defs.insert("LOCAL_SPACE_SIMULATION".into(), ShaderDefValue::Bool(true));

Bevy's own ShaderDefVal on the other hand has a bunch of existing conversions from string types, which make it a lot more convenient to work with:

https://docs.rs/bevy/latest/bevy/render/render_resource/enum.ShaderDefVal.html

I transitioned a piece of code from using Bevy's specialization pipeline etc. which used ShaderDefVal, to using naga_oil to validate shader code without having to bring the entire system-based infrastructure (because the code has some #if), and found it was more verbose. Nothing critical, but this would make usage smoother.

[robtfm]

not sure what to do here. i'm not very keen to make a struct/trait for the shader defs param since it adds complexity for people reading the source code. if there was some kind of mechanism for defaulting the values in a hashmap that would make sense, but i'm not sure there's anything which isn't at least as verbose (shader_defs.entry("KEY".into()).or_default()) ...

we can add From<bool> for ShaderDefValue so you could at least shader_defs.insert("KEY".into(), true.into()), or a default so you can shader_defs.insert("KEY".into(), default()), i guess that would help a bit.

[djeedai]

Ok maybe I didn't fully understand the problem. Bevy seems to have a ShaderDefVal that includes type and value and name of the def. naga_oil on the other hand uses ShaderDefValue only for the type and value part, and a separate string for the name. I didn't realize that when I opened the issue. And you're saying you don't want to do like Bevy, did I get that right? If so then yes indeed there's not much to be done here due to the HashMap interface.

[robtfm]

Right, I don’t want to make a type for name + value since I’d need to immediately convert it internally anyway.

[djeedai]

Ok makes sense. Let's close then.