You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Implementation-defined and implementation-specific #1802
[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:
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.
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:
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:
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?
(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.
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.
In "Terms and definitions," we have the following:
behavior, implementation-defined – unspecified behavior where each implementation documents how the choice is made
behavior, undefined – behavior, upon use of a non-portable or erroneous construct or of erroneous data, for which this specification imposes no requirements
behavior, unspecified – behavior where this specification provides two or more possibilities and imposes no further requirements on which is chosen in any instance
We now want to add behavior, implementation-specific. Here's my first try at a definition for that (which is intended to capture the sentiment of Nigel's suggestion):
behavior, implementation-specific – optional behavior or feature support that does not invalidate conformance and for which no documentation is required.
Activity
RexJaeschke commentedon Sep 9, 2026
[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:
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.
types.md:> Example:
inthas any implementation-specific members declared inSystem.Int32and the members (required and implementation specific) inherited fromSystem.Object, and the following statements are permitted: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:
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 commentedon Sep 9, 2026
Meeting results: Only action required is to define implementation-specific - and then check existing uses.
No milestone needed for this.
RexJaeschke commentedon Oct 6, 2026
In "Terms and definitions," we have the following:
We now want to add behavior, implementation-specific. Here's my first try at a definition for that (which is intended to capture the sentiment of Nigel's suggestion):
RexJaeschke commentedon Oct 7, 2026
We agreed to this on the 2026-10-07 call. Rex will turn this into a PR, which we'll merge.