LB--
commented
8 years ago There should be an easy mechanism to protect against major version changes being considered compatible, because by definition they are not.
Open LB-- opened 9 years ago
LB--
commented
8 years ago There should be an easy mechanism to protect against major version changes being considered compatible, because by definition they are not.
Many languages are versioned in such a way that several features, changes, etc. are added in each version. However, the tools and compilers for the language often don't update to support all the features at once - rather, individual features are supported at separate times, and the tool or compiler reports compatibility with either the previous version of the language or the next despite neither being true. Additionally, if a feature is supported but certain corner cases are not, and the feature is used multiple times, it is difficult to isolate which occurrences are problematic and which are fine.
Instead, it would make more sense to have a detailed way of testing feature support. Rather than versioning the language, individual features will be versioned and identified by a name string and a version string. (I'm not sure whether the version string should be traditional x.y.z or a date)
This way, compilers and tools can indicate which features and which versions of those features are supported, and whether there are any known bugs with specific versions. This would also allow easy nonstandard extension of the language. Thus the full identifier of a feature is its category string (standard, custom, some specific tool, etc), its name string (e.g. "multiple inheritance"), and its version string.
When requesting version information for a feature, the versions should be comparable by chronological order with the normal comparison operators, rather than by string comparison.
It is up to the user to decide whether features are required - simply raising a compile-time exception if a required feature is not supported should be sufficient.