Date: Sat, 6 Jan 2024 20:35:01 +0200
On Sat, 6 Jan 2024 at 19:37, Jens Maurer via SG16 <sg16_at_[hidden]> wrote:
> > I think I'd prefer if we just somehow say that implementations can define which Unicode standard they conform to. That way if a conforming C++23 implementation uses Unicode 15.1.0 (the latest version today) then it doesn't become non-conforming overnight when a new Unicode standard is published. We can recommend that implementations pin themselves to a recent Unicode standard, and even recommend that implementations should (if possible) update to use newer Unicode standards as they become available.
>
> Hm... That's not how normative references are supposed to work in an ISO world,
> I think ("pick the version you want" -- no), but we could certainly try that.
Well, that's how our normative reference to C works, for a standard
ISO considers obsoleted when we publish a new standard.
But how normative references work doesn't actually matter; what
Jonathan is asking for is that we add weasel-wording that
keeps old compilers conforming to the old standard, while allowing
them to update to a newer one - which is what actually
happens. An EOL compiler might not get updated, but it shouldn't just
become non-conforming because things move underneath.
The point isn't conformance in the strict ISO sense, the point is
being able to say that not updating an EOL compiler isn't
a conformance bug as such. It conformed to C++23, and remains so, and
the publication of C++26 or a newer Unicode
standard doesn't change that it conforms to C++23, which is
practically meaningful even if ISO likes to pretend otherwise.
> > But there's no way that a discontinued/EOL compiler version can get updated to a newer Unicode standard, which is what we seem to be requiring as a condition of being a conforming implementation.
>
> I don't think this problem arises in practice. Do we have a conforming implementation
> of C++ (which happens to be C++20 at this point in time)? This will stop being conforming
> in a few weeks when C++23 is published, at which point C++20 is considered withdrawn /
> superseded. And when C++23 is published, it will stay in force for about three years.
> Is there a conforming impplementation of C++23 already?
> Are compiler versions EOL'd in three years? At least for gcc, that doesn't seem to be
> the case.
Well, three years, four years, same difference. There is a point when
it becomes infeasible to backport Unicode-standard-related
updates, but that shouldn't make a compiler non-conforming to the
standard it was previously conforming to. You are correct
that this is unlikely to be a problem in practice, but it would sure
be nice if the specification would allow for the approach
implementations are going to use anyway.
> > I think I'd prefer if we just somehow say that implementations can define which Unicode standard they conform to. That way if a conforming C++23 implementation uses Unicode 15.1.0 (the latest version today) then it doesn't become non-conforming overnight when a new Unicode standard is published. We can recommend that implementations pin themselves to a recent Unicode standard, and even recommend that implementations should (if possible) update to use newer Unicode standards as they become available.
>
> Hm... That's not how normative references are supposed to work in an ISO world,
> I think ("pick the version you want" -- no), but we could certainly try that.
Well, that's how our normative reference to C works, for a standard
ISO considers obsoleted when we publish a new standard.
But how normative references work doesn't actually matter; what
Jonathan is asking for is that we add weasel-wording that
keeps old compilers conforming to the old standard, while allowing
them to update to a newer one - which is what actually
happens. An EOL compiler might not get updated, but it shouldn't just
become non-conforming because things move underneath.
The point isn't conformance in the strict ISO sense, the point is
being able to say that not updating an EOL compiler isn't
a conformance bug as such. It conformed to C++23, and remains so, and
the publication of C++26 or a newer Unicode
standard doesn't change that it conforms to C++23, which is
practically meaningful even if ISO likes to pretend otherwise.
> > But there's no way that a discontinued/EOL compiler version can get updated to a newer Unicode standard, which is what we seem to be requiring as a condition of being a conforming implementation.
>
> I don't think this problem arises in practice. Do we have a conforming implementation
> of C++ (which happens to be C++20 at this point in time)? This will stop being conforming
> in a few weeks when C++23 is published, at which point C++20 is considered withdrawn /
> superseded. And when C++23 is published, it will stay in force for about three years.
> Is there a conforming impplementation of C++23 already?
> Are compiler versions EOL'd in three years? At least for gcc, that doesn't seem to be
> the case.
Well, three years, four years, same difference. There is a point when
it becomes infeasible to backport Unicode-standard-related
updates, but that shouldn't make a compiler non-conforming to the
standard it was previously conforming to. You are correct
that this is unlikely to be a problem in practice, but it would sure
be nice if the specification would allow for the approach
implementations are going to use anyway.
Received on 2024-01-06 18:35:14