Restrictions on pointers passed to functions are not documented where they should be

[jimblandy]

WGSL permits formal parameters to user-defined functions to be pointers only if the address space is private or function. This restriction is not mentioned in the section "Restrictions on Functions", but it should be.

I hope I didn't just miss it, but I believe the only place in the spec that explains this restriction is the description of the unrestricted_pointer_parameters language extension. It seems odd to me to document a restriction only when explaining something that can remove it.

[alan-baker]

That was intentional since it is a language feature. The spec is written such that language features are assumed to be present to avoid having an accumulation of conditional language in the future.

[rcoreilly]

@alan-baker from an end-user's perspective, it is unclear when such features might actually get implemented, and this is a pretty big "non feature" right now that is very easy to miss, so on balance I would suggest that the effort required to update the spec later is probably less than the effort users will spend going down the wrong path because the spec doesn't really mention this critical aspect of the language as it stands now.

[kdashg]

Related: #5031

[kdashg]

WGSL 2025-01-28 Minutes

• JB: Rules say can pass whatever kind of pointer you want. If you notice the definition of the unrestricted pointer params it explains that unless the extension is available can only pass restricted kinds of pointers. Makes spec unclear as you have to do a computed come from to figure out what the spec was say. Function call section doesn’t say anything but random paragraph says rule is different. This is a deliberate spec choice as we didn’t want conditional language through the spec, makes it unreadable. Especially for widely deployed extensions. Firefox does not implement, Safari doesn’t state status or plans. I found unclear, community member also commented and as an end user it's unclear. If this was a feature where it was changing all over the spec with conditionals then would say lets just doc in on the description of the language extension. Because documenting this clearly does little change, would like us to tell people what the rules are in the place explaining the rules. Understand what Alan is saying, but in this case think it should be explained.
• KG: Willing to write a PR?
• JB: Yes.
• KG: Expect a PR showing how constrained the change is would make it easier to merge
• DN: Understand the concern and it's a sliding scale of how much change is needed. For example, if f16 was a language feature that would be everywhere. So, finding balance. Write a PR and will review.
• JB: To write a PR if he wants to push forward.
• DN: Goal is to make spec precise and then clear. Clear is close second. There are redundancies. Having worked with specs, any redundancy can be a problem in the long term.
• KG: In general, if we find something unclear, propose a clarity and we'll try to keep a running balance.
• Resolved: PRs will be entertained