Implementation-defined and implementation-specific

[jskeet]

Do we want both of these terms? Should we add them to terms-and-definitions.md?

[RexJaeschke]

[For completeness, I copied the email thread here.]

2026-08-30 Nigel

Just working on top level statements and the draft PR changed implementation-defined (ID) to implementation-specific (IS)in the opening para of §7.1. Curious I checked §3 – IS is not defined, and did a search – prior to this draft change there was only one occurrence of IS in §8.9.4.1 2nd para. There are 44 occurrences of ID.

I am leaning towards changing this IS back to ID, any reason not to? And maybe the one remaining IS too?

2026-08-31 Jon

I remember we talked about ID vs IS at some point to make sure we all agreed on the difference (and we did). Presumably IS is entirely stricter than ID, so removing IS in favour of ID isn't "breaking" in terms of conformance. If we've only got one IS and don't expect there to be more, I'd personally be okay with dropping it.

2026-09-01 Bill

I’ll defer to Rex, but I’m fine standardizing on “Implementation defined”. Functionally, it feels the same for me in terms of work. Either I have to specify the behavior, or I have to define it.

2026-09-04 Rex

According to draft-v14 (which has all proposed features up to and including V13), the text “implementation-specific” appears in the following places:

1. basic-concepts.md:A program may be compiled either as a class library to be used as part of other applications, or as an application that may be started directly. The mechanism for determining this mode of compilation is implementation-specific and external to this specification.

2. types.md:> Example: int has any implementation-specific members declared in System.Int32 and the members (required and implementation specific) inherited from System.Object, and the following statements are permitted:

3. types.md:The nullable context may be specified within source code via nullable directives (§6.5.9) and/or via some implementation-specific mechanism external to the source code. If both approaches are used, nullable directives supersede the settings made via an external mechanism.

The defined term “implementation-defined” requires a conforming implementation to document its behavior for some given situation.

The intent with “implementation-specific” is that the implementation need not document anything. I’d like to keep the distinction and not define it as a term as I think its ordinary English meaning is sufficient. Basically, it’s unspecified and outside the scope of the standard, which is almost but not quite the same as our defined term “unspecified behavior”.

2026-09-03 Nigel

I can see a distinction but would probably not define it the same way. Looking at the three examples:

1. Here there is a requirement in the Standard that code can be compiled as a class library or as an application. So I would say the mechanism is implementation-defined and should be document – i.e. how does it meet this requirement?
2. (This one is not in the v9-toplevel-statements branch which I was working on) Here whether there are any extra members is entirely optional, implementation-specific makes sense to me here.
3. Again whether there is an external mechanism seems to me to be optional (unlike case 1), so implementation-specific makes sense to me.

So I would say implementation-specific is for things which are optional and an implementation can provide, or not, them how it likes. For the purposes of conformance no documentation is required, hopefully for the purpose of users of the implementation they are.

Given Rex & I have slightly different interpretations of implementation-specific I think it should be added as a defined term – once we agree what they definition is of course!

I pushed #1454 yesterday, it has implementation-defined for (1) but feel free comment (Bill github wouldn’t let me add you as a reviewer, maybe you have it well trained ;-))

2026-09-07 Jon

Right, it looks like I'd interpreted implementation-defined and implementation-specific the wrong way round, which counts as another vote for "we should make these defined terms".

I've created #1802 as the simplest way of making sure we remember to discuss it on Wednesday.

[jskeet]

Meeting results: Only action required is to define implementation-specific - and then check existing uses.

No milestone needed for this.