Repository navigation
Missing design rationals #71
Description
I am missing a design rational for this proposal in the same vein as the design rational documents for the Wasm specification that can be found here: https://webassembly.org/docs/rationale/
One of the questions I was having is why this documents proposes to add the questionable null-reference and all the infrastructure (is_null) around it. To me coming from a C++ background it is quite confusing because semantically references should be assumed to always point to something, aka they are non-nullable pointers - same concept in Rust. Pointers in these languages on the other hand are nullable. However, there is also this interesting quote from the original designer of the null-pointer where he refers to it as a 1-billion dollar mistake: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
Which make people again wonder why we would want to repeat this in Wasm.
Note that I am not completely against adding nullable pointers to the Wasm spec I just really am in need of a rational of the why we cannot or do not want go without them.
There will be many more of those questions for upcoming Wasm proposals. Maybe we should enforce a dedicated rationals doc or section for all of them to quickly explain certain designs.
Activity
[-]Missing rationals document[/-][+]Missing design rationals[/+]rossberg commentedon Jan 8, 2020
We cannot get rid of null altogether, since some languages will need it. It also is present in current Wasm already, in the disguise of uninitialised table entries. And we currently need it (unfortunately) as an initialisation value for locals. (Just now we are having the null discussion for exception references.)
However, I think everybody agrees that there should ultimately be fine-grained control over null in the type system. Respective mechanisms are currently split out into the separate follow-up proposal for typed (function) references. The only reason for not including them here was the desire to start with a minimal proposal ot get off the ground quickly. And the presence of non-null ref types introduces a number of additional complications. Following the incremental strategy of evolving Wasm we'll hence add it in steps following a longer roadmap.
This larger road map admittedly is a bit difficult to extract from individual proposal repos. Respective discussions tend to be buried in GH issues and meeting notes, and it is of course changing constantly. We could probably do a better job at documenting it.
Robbepop commentedon Jan 8, 2020
Thank you for your response. Glad that you have already taken it into consideration. Now I understand the big picture a bit better.
This is exactly why I think that design rationals could be a nice requirement for Wasm proposals. When I was reading the base Wasm spec I was having sooo many questions behind certain designs until I found the design rational docs. Really one of my most loved Wasm docs so far.
Do you know where I can propose meta-stuff like requirement of a design rationale doc for all Wasm proposals? I think it would be very helpful for accelerating development of the Wasm spec in the long run.
binji commentedon Jan 15, 2020
@Robbepop I'd suggest bringing this to the CG meeting for discussion. See https://github.com/webassembly/meetings. As a first step you can file an issue there so we can discuss it.
Robbepop commentedon Jan 15, 2020
Done WebAssembly/meetings#481
Thanks for the info!
[interpreter] Refactor element type in passive segments (#71)