Policy: Implementation-specific rules?

[ehuss]

Should we ever allow implementation-specific rules?
If so, how should that be represented?

In the past, there has been a sentiment from some in the project to never allow that. I largely agree with that. However, I think there will be gray areas that will be difficult to navigate with such a prohibition.

[chorman0773]

Unspecified/nondeterministic is fairly well used within the operational semantics, and certain things outside of there basically have to:

• I'd say anything generally unstable needs to be unspecified in that instability (e.g. repr(Rust) structs/layouts), especially if we want to take the spec as authoritative on stability,

Additionally, I would generally regard rustc --target x86_64-unknown-linux-gnu and rustc --target aarch64-pc-windows-msvc as being separate "implementations", insofar as they have different input parameters to the emulated abstract machine. Target-defined is, IMO, a subtype of implementation-defined.

[digama0]

Additionally, I would generally regard rustc --target x86_64-unknown-linux-gnu and rustc --target aarch64-pc-windows-msvc as being separate "implementations", insofar as they have different input parameters to the emulated abstract machine. Target-defined is, IMO, a subtype of implementation-defined.

I don't really agree with this. I would expect a rust spec to say that size_of::<usize>() == 8 when compiling for the target x86_64-unknown-linux-gnu and this is not an implementation choice. This is just as much defined behavior as x + y performing a panicking add on debug and wrapping on release. I don't think we should copy the C/C++ practice of lumping together target-specific and implementation-defined behavior.

(This does not address the practical aspects of actually documenting all 100+ targets in the spec. This is just an aspirational statement about how I think the spec should be in the absence of other constraints.)

[ehuss]

Target-defined is, IMO, a subtype of implementation-defined.

Thanks for bringing that up. I think it is a distinct enough question that I forgot to include, and opened #44 for that.

[ehuss]

Closing for rust-lang/reference#2040