Add goals, non-goals, risks

[rossberg]

To clarify the scope of profiles.

@conrad-watt, PTAL.

[sunfishcode]

A subtlety here is that relaxed-math mode is proposed to be framed such that deterministic mode is the prominent mode in the spec, and relaxed mode is an alternate superset of it. In particular, the hope is that by doing so, we can contain the new list nondeterminism behavior within this mode. I wonder if that's feasible within this profiles framework.

I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?

[rossberg]

I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?

Yes, semantically that would work. Editorially, the list semantics would still have to be part of the main spec, but practically overridden by set determinism, unless that is disabled by a profile.

In general, the main body of the spec has to specify the union of all possible behaviours. So unfortunately, we cannot technically shove out non-determinism there.

[conrad-watt]

A subtlety here is that relaxed-math mode is proposed to be framed such that deterministic mode is the prominent mode in the spec, and relaxed mode is an alternate superset of it.

Personally, I have a somewhat strong opinion that we should frame things in terms of a "full/default" profile and a (clearly marked alternative) "deterministic/strict" profile/mode. The safe thing for users to do is to write/compile/produce their program anticipating the non-deterministic semantics, because then moving to a "deterministic/strict" implementation is safe. If we message that the deterministic semantics is the "normal" one, and this bleeds into documentation or tooling, I worry that we'd be creating a hazard for users.

I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?

Given the intended use-cases of qfma I think even the full profile is going to need list non-determinism.

[sunfishcode]

Also, could I suggest rephrasing this bullet along the lines of "Process short-cutting. Blessing the notion of language subsets may reduce the perceived need for scrutiny or consensus-building when adding new features. Such an approach would still increase fragmentation as well as adversely affecting the overall complexity budget and reputation of the language."

[rossberg]

Good point, reworded.

[rossberg]

Thanks for the review!

[rossberg]

I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?

Yes, semantically that would work. Editorially, the list semantics would still have to be part of the main spec, but practically overridden by set determinism, unless that is disabled by a profile.

In general, the main body of the spec has to specify the union of all possible behaviours. So unfortunately, we cannot technically shove out non-determinism there.

[rossberg]

Good point, reworded.

[conrad-watt]

I think we need to give some thought to how the existence of profiles affects users and producers.

Profiles that only support a subset of instructions are only useful if there are producers that offer an option to avoid generating the excluded instructions.

Profiles that subset semantic behaviour like non-determinism may also attract producers to exploit this (e.g. using qfma as deterministic fma).

There's also a real difference between the two above. Inadvertently producing code for a syntactic subset is safe, and will still run correctly on "full" implementations. Inadvertently producing code for a profile-blessed semantic subset is hazardous, because it may rely on assumptions that aren't true in "full" implementations.

I think the following should be true (not attached to exact wording):

• There should be a "full" profile, and other profiles may only present subsets of instruction availability and non-deterministic behaviour in comparison to the full profile.
  • The intention is that code produced for the full profile should either work correctly, or fail at latest at validation time with "feature not supported" on other profiles.
• Producing code for the "full" profile should always be the default, and alternatives should be clearly messaged.
  • Users should especially be protected from inadvertently producing code for a profile that subsets semantic behaviour (i.e. less non-determinism).
• Profiles should always be mutually compatible and composable. No two profiles should subset semantic behaviour in different ways.
• Runtime conditioning on the current profile should be avoided at all costs, both at the language-level, and at the toolchain/platform level. Users should "lock in" to a target profile at produce-time, and know at deploy-time which profile their code will run on.

[rossberg]

That makes sense to me, but do you suggest including these points as a goals/risks, or discussing them separately somewhere?

One comment, though:

Inadvertently producing code for a profile-blessed semantic subset is hazardous, because it may rely on assumptions that aren't true in "full" implementations.
[...]

• Users should especially be protected from inadvertently producing code for a profile that subsets semantic behaviour (i.e. less non-determinism).

I'm not sure this problem is qualitatively different from the one we already and inevitably have regarding future extensions. For example, we discussed that code might be assuming to know the subset of all subtypes of, say, eqref, which obviously is a bogus assumption.

How do you suggest detecting and protecting against such misassumptions?

[conrad-watt]

I think there needs to be some explicit acknowledgement of "risks" from a user/producer point of view. For a user - inadvertently producing (for example) "strict" code that they then deploy to the Web. Similarly for a toolchain - confusing users with multiple/hazardous options and dealing with attendant compositionality problems. I think this is somewhat under the "fragmentation" theme but the difference is that the user experience problem is an inherent risk of profiles that we can't mitigate purely through specification language/process (unlike the existing "inflation", "short-cutting", "abuse" risks).

I'm not sure this problem is qualitatively different from the one we already and inevitably have regarding future extensions.
...
How do you suggest detecting and protecting against such misassumptions?

Some of the specifics of my post could be put elsewhere, but do think the design restrictions above should be prominent somewhere. At the very least we should have everyone active in the CG agreeing on them (esp. toolchain people). I agree some of the above is a matter of social responsibility - e.g. having some "only use this if you know what you're doing" documentation around a producer flag for "strict" - but there are some spec principles here - e.g. having a "full" profile and compatibility/intersection between different profiles, ensuring that toolchains always have a sensible "default" to offer users.

[conrad-watt]

Just to turn this into something actionable, as far as this PR goes I'd be happy with just a couple of sentences being added to the "risks" section flagging up user experience issues to do with toolchain use and targetting the wrong profile. My other points can live somewhere else.

[rossberg]

I added a risk item on "over-optimistic assumptions" (for lack of a better title), and a section on Intended Properties, mostly copying your items above. PTAL.

[ttraenkler]

In the above I considered less determinism a risk to correctness of the algorithm, while this seems to be motivated by more determinism being a risk of a potential performance degradation?

I think the opposite is more practically likely - targetting a more deterministic environment can create correctness hazards for users who accidentally then use the code in a less deterministic environment. The safe thing is always to target the lowest common denominator ("full").

My mental model is kind of reversed. In my understanding a "lowest common denominator" of all wasm runtimes would imply features that all of them support, which is kind of core Wasm 1.0. In reality over time we're adding features, not taking them away and then use profiles to restrict them for various reasons, so a full profile would be expanding and not be the lowest common denominator for a runtime that does not support SIMD or GC for example.

Consider a user who writes a C++ program using std::fma. If they inadvertently compile their code targetting Wasm in the "deterministic" profile, and then deploy it in an environment that implements the "full/relaxed" Wasm, their code will likely break as the fma will be compiled to relaxed SIMD's relaxed_madd, which is the most efficient scheme but only correct if the Wasm environment is "deterministic". Conversely, if they inadvertently compile their code to Wasm in the "full" profile, and then run it in a "deterministic" environment, they may lose some performance because fma will be compiled less efficiently, but nothing will semantically break.

I see, I am more coming from the assumption that modules are provided as .wasm binaries from a registry and would not be compiled by consumers. In that case the instruction would already be baked in, so changing the profile in Wasm land would refuse to compile the module as "not compatible with this profile". I see the profiles more living in the Wasm runtime when compiling .wasm modules checking if the module complies with the profile and setting a code path - a view which is outside the scope of this proposal but could be complementary and interesting for feature detection.

I agree if the producer provides a profile it could be "full (speed)" by default (and maybe Wasm version to target for backwards compatibility), but it would have to be explicitly provided, otherwise core Wasm 1.0 assumptions are violated. If not provided, by default compiling a module "without a profile" core Wasm 1.0 should be assumed, not including extensions like SIMD at all. If they do restrict the profile I agree this needs to be documented and configured in their toolchain to avoid setting the wrong flags and maybe a profile check on the produced .wasm module done to verify, but it's hard to standardize beyond general recommendations.

[ttraenkler]

Another thought, not sure if this has been considered yet: I think it would make sense to bake in the profile which a module has been compiled with into the .wasm module into a section, so a case as you described where the producer "messes up" would be detected by the Wasm runtime during compilation.

[conrad-watt]

but it would have to be explicitly provided, otherwise core Wasm 1.0 assumptions are violated. If not provided, by default compiling a module "without a profile" core Wasm 1.0 should be assumed, not including extensions like SIMD at all

To some extent this is already a concern that shows up in both JS and Wasm - I brought up the bulk memory example which Binaryen has agonised over (emscripten-core/emscripten#15376). I don't think we should look to profiles as a clean solution to this, as it's essentially a versioning issue. @tlively previously said in the above issue "We previously decided to be somewhat aggressive about updating LLVM defaults (default after phase 4 + 6 months, IIRC)" - I don't know if this is still the case and whether SIMD would ever be enabled by default.

EDIT:

Another thought, not sure if this has been considered yet: I think it would make sense to bake in the profile which a module has been compiled with into the .wasm module into a section, so a case as you described where the producer "messes up" would be detected by the Wasm runtime during compilation.

I need to think more about this! Instinctively I feel that it's preferable not to have a "runtime" check like this, but it may be the lesser evil.

[ttraenkler]

To some extent this is already a concern that shows up in both JS and Wasm - I brought up the bulk memory example which Binaryen has agonised over (emscripten-core/emscripten#15376). I don't think we should look to profiles as a clean solution to this, as it's essentially a versioning issue. @tlively previously said in the above issue "We previously decided to be somewhat aggressive about updating LLVM defaults (default after phase 4 + 6 months, IIRC)" - I don't know if this is still the case and whether SIMD would ever be enabled by default.

With profiles this might be resolved without versioning, you could provide a profile that the compiler understands and adopts their defaults to. As you mentioned "aggressively" implies breaking code since the defaults were updated, which could be solved by a profile with the previous defaults, which the module should ship with to to declare its needs.

[ttraenkler]

EDIT:

If say in the worst case the module has been produced years ago and is no longer maintained, users will cut their finger using the module in a full profile that now allows non deterministic behavior. I would tend to opt for explicit opt-in of extensions with considerable tradeoffs to initial core wasm e.g. that are a breaking change in semantics like relaxed SIMD introducing new non determinism by not including this in a full profile, so at least someone needs to enable this explicitly.

Relaxed SIMD isn't expected to cause this kind of problem, because the non-determinism is only present in new instructions the proposal is adding. With or without profiles, it will never be the case that we make a proposal to add new non-determinism to existing instructions in a way that affects previously-produced code at rest - this would break Web compat.

We should move the discussion over, but since this is a subtle issue that might be lost by losing context, answering your edit here:

It might not be common, but I would not expect this in general: In a similar scenario to the ones you described flipping a compiler switch or changing toolchain defaults, if the module in an old code base is just recompiled e.g. for fixing a typo, a contributor with a newer compiler supporting a new instruction, with a full profile you might produce a module with instructions not considered, changing the implicit profile of the module. In this case all bets are off if this is no longer matching the implicit contract agreed on between the producer and the consumer.

This touches on how and where a module's interface contract is defined, validated, and guaranteed to be stable, explicitly or implicitly and how we best ensure it is not broken over time. If it is implicit in the source code and the version and flags of the toolchain used, as you have mentioned this is rather subtle and fragile.

I think there is great value in explicitly declaring the assumptions of a module being produced or consumed in a profile shipping with the module and validating against this at the time the module is produced and consumed. It seems to me this is part of the contract between the producer and consumer and in my mind lives closest to the space of WebAssembly Interface Types (WIT) contracts for modules as the implications might affect the long term stability of standardized interfaces, possibly beyond a specific module.

[lukewagner]

After more-recent discussions of this with folks at the in-person CG, I've started to question whether we need the general-purpose/generic mechanism of "profiles" or whether we should start only a single "deterministic mode".

In particular, w.r.t:

• GC: if a source language fundamentally needs GC, then a host-implemented GC shouldn't have any heavier resource requirements than a wasm-guest-implemented GC. Quite the contrary: the toolchain compiling a GC langauge to linear memory is forced to pick a single impl scheme with a fixed tradeoff whereas host-implemented GC can tailor the GC impl to the host's resource constraints. (This is one of the subtle wins of wasm-GC outside the browser.)
• Removing features to reduce engine size/complexity: given the concrete ecosystem fragmentation costs Conrad outlined above, I think we should wait to see the need for these kinds of profiles emerge from production deployments of wasm before speculatively creating profiles (that might end up otherwise capturing the wrong host requirements). That is: let's only do this if absolutely necessary, not speculatively.

[titzer]

I think there are many embedded processors which will not support vector instructions and are likely to want to support a profile without SIMD. While I too hope that GC becomes widely supported across engines, I can see a path where some engines don't support GC, but instead support multi-memory, and there is a polyfill.

[conrad-watt]

I would be happy for the "profiles" proposal to be purely about setting up a conceptual framework for handling profiles (backed by consensus polls but not necessarily a phase advancement process), and then each individual "profile" has to be separately justified by an implementer approaching the group.

EDIT: that's effectively our justification for the "deterministic" profile, with @lukewagner and others putting forward a cloud perspective at the in-person meeting.

[titzer]

each individual "profile" has to be separately justified by an implementer approaching the group.

What about a future where there are severely constrained profiles for oddball scenarios, e.g. a programmable routing mesh that doesn't allow more than 1 page of memory, no tables, no call_indirect and no loops? That's not necessarily something every toolchain would want to target, but rather a programmable thing in need of a code format.

I sense there is tension between the goals of avoiding ecosystem fragmentation and also broad adoption. I'm not sure we want the CG to be the bottleneck for new, unenvisioned use cases for Wasm popping up that are likely to subset it in unanticipated ways. Or are those just not "profiles"?

[conrad-watt]

Or are those just not "profiles"?

I think it's important for us to be conservative (and to be clear, we hopefully wouldn't say yes to every profile suggestion). Profiles could be thought of as "blessing" a small number of particularly fundamental (and conceptually well-demarcated) use-cases in the core spec, so it's not unreasonable that the CG is a bottleneck. Experimentation can happen independent of this - if someone wants to fork the spec and frame their oddball usecase/restrictions as a "profile" they write themselves, more power to them, but it shouldn't be necessary.

[rossberg]

Strongly agreeing with @conrad-watt that we should be very conservative with profile introduction, and only consider clear-cut and broad use cases, not oddball scenarios. I intentionally list the risk of "profile inflation". ;)

[lukewagner]

Agreed with @conrad-watt that it would make sense to introduce the conceptual framework of "profiles" up front but to require each new profile to be voted on independently based on concrete (and I'd add some fuzzy notion of "used at large") implementations approaching the group and making the case for a particular profile. I'm happy to help make the case for the deterministic profile so that we have at least one. But I don't think we should speculatively add the other ones up-front, at least without some more evidence from implementations that they're necessary. And yes, there's nothing stopping an implementation from simply shipping whatever ad hoc subset they want -- the question for the CG is when to bless particular subsets with a "profile", thereby imposing the burden on the broader wasm ecosystem (particularly producer and distribution tooling) to have to worry about this profile and what's their "story" for that profile.

[rossberg]

I think we'll need a more nuanced approach. There is functionality for which it is obvious that certain environments do not have the ability or capacity to implement it: GC, stack switching, threading, SIMD, all come to mind.

Nobody is helped if we pretend this reality doesn't exist. We'd just create more fragmentation and tooling issues, not less. And alienate some of our customer base.

In particular, we have to ensure that no language extension represents a regression for an existing part of the Wasm customer base. If we, e.g., were to land GC without a profile to opt out of it, then we'd be unhitching some customers from the progression of the language and put them in a limbo state where they're technically no longer able to adopt the effectual version of the standard. We'd be pulling the rug under them, which is not something we should do!

Hence, it is actually key to make the consideration of suitable profile integration part of the proposal process. No non-trivial proposal should land that knowingly breaks relevant customers. For the same reason, we need to fix the situation for SIMD asap, since we already do know that we have regressed for some customers.

[conrad-watt]

I want to push back a little - I think that a necessary (but not sufficient) requirement for a profile to get in the spec should be that at least one implementation is actively planning on restricting itself to that profile and cares about the spec enough to tell us. I worry that a profile for each major spec feature is going to to end up looking very similar to versioning.

[titzer]

I worry that a profile for each major spec feature is going to to end up looking very similar to versioning.

It depends on how we ultimately define profiles. For example, is there an "embedded profile" that becomes a bin that we would major spec features into one-by-one, or are profiles negatively defined, i.e. the "no SIMD profile". Are profiles feature sets that can be mixed and matched?

[ttraenkler]

I worry that a profile for each major spec feature is going to to end up looking very similar to versioning.

It depends on how we ultimately define profiles. For example, is there an "embedded profile" that becomes a bin that we would major spec features into one-by-one, or are profiles negatively defined, i.e. the "no SIMD profile". Are profiles feature sets that can be mixed and matched?

I agree general higher-level profiles that group possibly over time expanding sets of features like "embedded" or "performance" would make sense, and then allow to override them, but positively and negatively, say "performance" AND "deterministic" would restrict the "performance" features to deterministic ones, or "embedded" OR "GC" would override the embedded profile only to extend it by this feature. While this is not versioning as it's not linear, it might prove useful to express additional version profiles like "core wasm 1.0" "core wasm 2.0" to include sets of features to make it less verbose to target an evolving standard over time.

[rossberg]

I want to push back a little - I think that a necessary (but not sufficient) requirement for a profile to get in the spec should be that at least one implementation is actively planning on restricting itself to that profile and cares about the spec enough to tell us. I worry that a profile for each major spec feature is going to to end up looking very similar to versioning.

To clarify, I don't mean to imply that every major feature needs an opt-out, but that the potential need for opt-outs ought to be considered for major features. That may well result in no action needed, it may also result in an existing profile being sufficient to cover it (e.g., the deterministic profile for relaxed SIMD).

[lukewagner]

I don't think discussing various profiles in the abstract will be too fruitful without some actual embeddings showing up and describing their concrete constraints that prevent them from supporting a feature. Also, I think that's the attitude we should take with core wasm: this should be a collection of features that every implementation would want to support unless they have a hard reason not to. If we don't take that attitude, then I think we'll end up with a bunch of lower-value instructions justified by "you don't have to support it if you don't want to" which would in turn lead to unnecessary fragmentation and break what is currently one of wasm's key value propositions.

[ttraenkler]

I don't think discussing various profiles in the abstract will be too fruitful without some actual embeddings showing up and describing their concrete constraints that prevent them from supporting a feature.

Definitely, I believe what we discussed to be placeholders to illustrate a conceptual framework and general mechanism that could be evaluated empirically, easier to reason than just talking about A and B.

Also, I think that's the attitude we should take with core wasm: this should be a collection of features that every implementation would want to support unless they have a hard reason not to. If we don't take that attitude, then I think we'll end up with a bunch of lower-value instructions justified by "you don't have to support it if you don't want to" which would in turn lead to unnecessary fragmentation and break what is currently one of wasm's key value propositions.

Agreed. That's why I do think a kind of core WASM versioning profile in form of core WASM 1.0,. 2.0 as the default would be a strong signal what implementers should support and put us in a better position than scattered support and feature detection on the web. (With the discussed models a profile 3.0 could also discourage using a feature that is still there in terms of backwards compatibility but has been deprecated but could be overridden by continuing to use an old profile or extending the profile.)

[conrad-watt]

Agreed. That's why I do think a kind of core WASM versioning profile in form of core WASM 1.0,. 2.0 as the default would be a strong signal what implementers should support and put us in a better position than scattered support and feature detection on the web.

I do want to point out that the current vision for profiles is explicitly not aiming to solve this problem (as called out here).

Honestly mis-managing ecosystem expectations here is enough of a hazard that I've almost talked myself into agreeing with @lukewagner's previous comment. The usecase of profiles in semantically subsetting behaviour is somewhat distinct from the usecase of syntactically subsetting features, and I'm beginning to question the importance of the latter. Producers already have granular flags for enabling/disabling features, and I'm not sure that the user experience of "picking the wrong syntactic profile" is so different from "enabling the wrong feature flags". In both cases the environment will error with "instruction not supported" (and presumably document which flags/profile should be selected in the producer).

[rossberg]

As I recall it, there was a strong sentiment at the time we started discussing GC that we can only add such a thing when it remains optional.

[ttraenkler]

The usecase of profiles in semantically subsetting behaviour is somewhat distinct from the usecase of syntactically subsetting features, and I'm beginning to question the importance of the latter. Producers already have granular flags for enabling/disabling features, and I'm not sure that the user experience of "picking the wrong syntactic profile" is so different from "enabling the wrong feature flags". In both cases the environment will error with "instruction not supported" (and presumably document which flags/profile should be selected in the producer).

I thought about the same thing. I concluded I believe it's worth having a profile declaration shipping with the module to validate the compiled module still complies with the requirements to prevent the scenario you described where a compiler flag is switched (or the default of the toolchain changed silently), so it would be good to be able to describe, ship and validate such a profile in the producer's toolchain as an afterstep to compilation so the profile cannot accidentally change and the producer can describe the intended supported scenarios.

[ttraenkler]

The usecase of profiles in semantically subsetting behaviour is somewhat distinct from the usecase of syntactically subsetting features, and I'm beginning to question the importance of the latter. Producers already have granular flags for enabling/disabling features, and I'm not sure that the user experience of "picking the wrong syntactic profile" is so different from "enabling the wrong feature flags". In both cases the environment will error with "instruction not supported" (and presumably document which flags/profile should be selected in the producer).

Also, maybe relevant in a broader context, a Wasm profile could be used to declare requirements as consumer constraints in the context where the module is used during compilation from the .wasm module to machine code, it could be a hint to the compiler it can strip out certain alternative but unused/dead code paths or compile the module despite not supporting a certain feature if there is an alternative code path. None of this is needed for an MVP, but it would be good to at least not rule out these options accidentally without discussing them.

[lukewagner]

@rossberg

As I recall it, there was a strong sentiment at the time we started discussing GC that we can only add such a thing when it remains optional.

IIRC, much of that sentiment was mine ;-) I think a newer, more-nuanced sentiment (that I've heard shared by a number of folks) is: in adding new features to wasm, we should not force GC on languages that do not fundamentally require GC but want to use the feature (e.g., stack-switching). Thus, the languages that need GC are doing GC in any case (in linear memory or in host memory via wasm-GC) and the languages that don't aren't.

[rossberg]

@lukewagner:

IIRC, much of that sentiment was mine ;-)

It's nice of you to take the blame, but that's not what I remember. ;) A significant portion of the room was highly uncomfortable with the idea of adding GC to Wasm, and to force it on every engine. And rightfully so, I should add.

To clarify again, I'm not suggesting to design profiles randomly or inflationary. Profiles are meant to address the case where we want to add functionality to Wasm of which we know for a fact that it is impossible to implement in a meaningful manner on some relevant hardware, OS, or other form of platform. When adding such functionality, we have 3 choices:

1. Ostracise platforms that cannot support it, effectively telling them to use another code format. By that, we would decimate the scope of Wasm. And we would break existing customers that chose Wasm in good faith.
2. Ignore the problem and pretend it doesn't exist. That will just lead to ad-hoc designs and uncontrolled fragmentation in the wild. It's not realistic to expect that customers will come to the CG and ask for its blessing.
3. Embrace diversity and proactively address it with profile support that reconciles conflicting goals and confines fragmentation. To that end, very few profiles could cover a wide range of features.

Maybe I'm missing something, but I have a hard time understanding how (1) or (2) could be more beneficial strategies than (3). From what I can see, they would neither serve the standard nor its users.

[lukewagner]

I don't think we fundamentally disagree, given that you're saying the condition for adding a profile is "we know for a fact that it is impossible to implement". The point here isn't to never add profiles, but to only add them based on sufficient evidence and demonstrated significantly-widespread implementations that in fact have the constraints that motivate the profile. I don't think we've seen this for non-GC and non-SIMD yet, but I'd certainly be open to see more evidence.

[titzer]

I don't think we've seen this for non-GC and non-SIMD yet, but I'd certainly be open to see more evidence.

Both wasm3 and wamr are runtimes targeting embedded systems. They are each a little behind the current standard (hopefully they will catch up). But given that these runtimes are targeting embedded systems and run on several odd-duck processors that are likely never to have SIMD, a "no SIMD" profile seems reasonable to me. Or did I misunderstand what you meant?

[lukewagner]

I think we should hear from the folks who actually work on those engines rather than making judgements in the abstract on their behalf. For example, iiuc, the two engines you mentioned are interpreters, so it doesn't really matter what the CPU supports.

[titzer]

WAMR has a JIT now.

[conrad-watt]

LGTM from the pov of the document, but I think the discussion in this thread needs to continue.

[conrad-watt]

I would say "inconsistent" or "mismatched" assumptions here

[rossberg]

Changed to "false".

[rossberg]

I suggest we continue the discussion on issue #1, which already raised the same question.