-
Notifications
You must be signed in to change notification settings - Fork 454
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[spec] Rename start function #1073
Comments
IMO “init” is so short and useful sounding that it will suffer the same problems we are trying to avoid. I would prefer something more cautionary such as “internal_init,” which was also suggested at the CG meeting. My other concern is how this might affect the W3C standardization process. Does anyone have details on that? |
Any decent name is gonna be in some form of conflict, and this no different from names like "data" or the likes. Adding a prefix to "init section" seems a bit odd and unnecessary to me, given that there is no other notion of init section. I suppose the concern is not really about "init section" but about "init function". But given your conditional compilation proposal, there won't be the init function anymore anyway. Nor is any such function necessarily used only in the init section. Maybe it's sufficient if we simply avoid the term "init function" in spec and docs? FWIW, my first motivation for the rename isn't so much preventing naming conflicts, but semantic confusion about the role of the init section: it does not start the module, it merely initialises it, and this is really the analogue to an init section in other formats, so I'd like to use that name. |
I agree that the motivation for the rename is semantic confusion, but I fear that a rename to “init” will not entirely clear up the confusion. I anticipate answering lots of questions about how people can write their own init functions to “initialize” their module, which is the exact problem we have today. To solve the problem, the name needs to be scary enough to communicate that the section/function(s) is off limits for regular users. |
Hm, what's a "regular user" in the context of Wasm? Its direct users are primarily compiler writers, and I suspect that most of them generally have to use the init section one way or the other. Are you concerned about the users of those compilers? Why would it matter to them? |
Yes, I'm concerned about the users of those compilers. We frequently get requests from users of various WebAssembly-targeting toolchains about how they can write their own start functions because they want to have some code run automatically on startup. They read about WebAssembly a bit and see that it supports start functions and think that this is exactly what they want. If they see that WebAssembly supports init functions instead, they will still think that they can solve their problems. But hopefully if users see that WebAssembly supports "internal_init" functions they will not be tempted to try to use them. Here's one from this month on llvm-dev: https://lists.llvm.org/pipermail/llvm-dev/2019-October/135940.html |
Well, that's why I suggest avoiding the term init function. ;) I don't see much evidence that awkward naming would avoid questions like the one you link (there's plenty of much more serious confusion about other aspects of Wasm everywhere). OTOH, I'd assume that for some people "internal_init" is actually more confusing -- the init section is no more internal than anything else in a Wasm module that isn't exported, but looking at the name they'll wonder what's special about it? As if there was some form of privilege attached that isn't attached to, say, the data section. |
Seems like we didn't make much progress finding a new name here. Are we giving up on this because since wasm is now a REC? Or do we want to try to push forward with a new name? |
It doesn't seem like we will be able to find a name that everyone agrees is enough of an improvement over the current name to be worth the work of changing names. If part of the solution is updating docs to prefer referring to what is currently called the start section over referring to what is currently called the start function, I recommend that we do so without renaming. |
Sorry for not pushing forward. I still think it would be beneficial to change the name. Not so much to avoid all confusion (we will never succeed with that) but because "start function" is actively misleading, and even bogus when generalised to multiple of them, like in the feature detection proposal. Module "initialisation" at least does not evoke the wrong association, even if it may still be ambiguous in some contexts. I think that is a qualitative improvement. I would try to minimise ambiguity-based confusion by only talking about the "init section", which is a well-established term in binary formats. With multiple functions in there, any reference to "the" init function will be wrong anyway, so I would simply avoid the term altogether and just speak of "functions in the init sections" (if necessary at all). As far as I can see, that resolves all issues. FWIW, I am still not fond of artificial qualifiers like "internal init" -- as argued above, I think that would actually increase confusion in other ways. |
I see what you mean, though it sounds like we could solve the same problem you're describing by calling it the "start section" instead. As you've mentioned, "init" is likely a better fit but I wonder if it's better enough to warrant changing all the tools. |
Fair enough. I don't see a lot of appetite for changing this, so I'll close. |
There has been ongoing confusion about the role of the Wasm start function, what it can do, and how it is different from the exported
_start
or*start*
function convention used in some environments -- see e.g. WebAssembly/design#1160 and links from that discussion. In the 2019/09/17 meeting, the CG hence voted in favour of renaming the notion of start function.This is almost entirely an editorial change to the spec, except for a corresponding adjustment of the text format (see below).
I propose to rename it to "initialization function" (or "init function" for short); accordingly, the respective section in the binary format would then be called the "init section". That better fits its ability to run initialisation code for a module's state that is guaranteed to be executed before the module becomes available (similar to a class constructor in OO). It also corresponds closely to the notion of init sections in other binary formats.
For the text format, we will then want to allow using the keyword
init
instead ofstart
to declare this function. There are three options for this change and what to do with the original syntax:start
keyword immediately, requiring existing code to be adjusted.start
keyword, but keep it for a while until existing code has been adapted.start
indefinitely as a synonym for backwards compatibility.Note that the
start
keyword is one of the more exotic features of the Wasm text format, and probably not used a lot outside test code.Thoughts?
The text was updated successfully, but these errors were encountered: