-
Notifications
You must be signed in to change notification settings - Fork 18
Description
I really like the idea of the "Feature Maturedness" page, but I think it can be improved. I have a couple ideas to consider:
-
Link each listed feature to the spec or some documentation. For example, I know that there is experimental support for "
as
andis
operators", but I don't actually know what they do (perhaps that is an unfair example since the page is so new and that feature is experimental, but I think it gets the point across). Or another example, I see that Raytracing is defined as stable, but where can I learn about Slang's syntax for raytracing features? -
I don't think Status deserves its own column in the table. I think it is overly verbose. Right now, we group features alphabetically ascending by descending stability. If we want to continue this trend, we could simply have a Stable list, Public review list, and Experimental list. However, there may come a time when we want to group features into categories / by topic. In that case, I would recommend a color code to concisely indicate status. I think something like:
- Stable = 🟩
- Public review = 🟨
- Experimental = 🟥
would look nice, but then again, we may want to consider colorblind people. Maybe:
Feature | Notes |
---|---|
... | ... |
S 🟩 Vulkan Interop (scalar layout, -fvk-* options) | |
E 🟥 Associated types for static dispatch | Has been there for a long while with a lot of user code adoption |
... | ... |
I would like to hear other opinions on the topic.