search

whatwg / webidl

Web IDL Standard
https://webidl.spec.whatwg.org/
Other
410 stars 164 forks source link

How are name conflicts specified? #1411

Closed srujzs closed 5 months ago

srujzs commented 5 months ago

What is the issue with the Web IDL Standard?

With the addition of this draft, the Web IDL now specifies two operations with the same name as their return type: https://github.com/w3c/webref/blob/3375fbd9df4df1c72620921ce875766f84983288/ed/idl/saa-non-cookie-storage.idl#L32.

This presents issues in languages that may provide bindings for these APIs, as you now have a name conflict. It isn't clear if this naming scheme is working as intended, and I can't determine from the spec what other name conflicts/scoping rules to watch out for.

nektro commented 5 months ago

the method is globalThis.StorageAccessHandle.prototype.BroadcastChannel and the return type is globalThis.BroadcastChannel from https://html.spec.whatwg.org/#broadcastchannel

bhathos commented 5 months ago

What is the conflict that’s referred to in the issue title? Web IDL doesn’t seem to currently forbid this, but I’m not spotting any ambiguity so far, and given Web IDL members aren’t types and don’t declare types, I’m not sure how there could be one. The identifier terminals in DistinguishableType :: identifier Null and ConstType :: identifier reference type names, not member names.

There are already interfaces and members that have the same names on the web platform, e.g. the URL interface and the URL member of the Document interface, though I’m not 100% sure how Web IDL would currently handle the case where the member belongs to a [Global] interface, which seems like a way that things could plausibly end up gettin’ weird. I don’t know if there are any extant examples where the the return type of a member with a particular name is a type referenced using the same name, but I also didn’t see anything that would make this scenario significant.

Is this issue about a different language? That’s suggested by “issues in languages that may provide bindings”, though I’m unsure what “may provide bindings” means there. If this issue was prompted by needs related to a particular binding, what language was it? Are Web IDL binding behaviors currently specified / being specified for that language or did the issue arise in something more ad hoc?

srujzs commented 5 months ago

Sorry, to be a little more specific, the conflict is referring to the type and the operation name having the same name. In my specific case, we use interop to provide interfaces for browser APIs in Dart. Dart disallows you from declaring a member with the same name as its return type e.g.

class A {}
A A() {} // error

This issue doesn't occur with the URL case presumably since the use of the type URL isn't in the same declaration as the declaration of the member URL. C++ seems to be okay with similar code, although it does warn you that you're changing the meaning of A.

Regardless, it seems like this is well-defined and there's precedent, so it's a matter of me handling this specially to account for language differences. The other name conflict I've come across is operations having the same name as static operations (which also is an issue in Dart), which we already handle specially. I'll mark this as closed.