On Sat, 2018-03-17 at 20:57 -0500, Rene Rivera wrote:
> On Fri, Mar 16, 2018 at 8:30 AM, Torvald Riegel <triegel_at_[hidden]> wrote:
>
> > On Thu, 2018-03-15 at 22:46 -0500, Rene Rivera wrote:
> > Open specification (3)
> > >
> > > The possibilities of the specifics of what a PDM and build system can
> > > accomplish is open ended. And as we see from current compiler solutions,
> > > and technological innovations, it's a quickly changing landscape. We need
> > > specifications that are flexible enough to grow and adjust faster than
> > the
> > > core C++ Language standard has evolved so far. This implies that we can't
> > > follow the current model of the standards process to accommodate this
> > > flexibility. We need a standards model that allows for new specifications
> > > "outside" of the core. There is one group of standards that follows an
> > open
> > > model we can borrow from, OpenGL. OpenGL's core specifications with added
> > > extension specifications allows for quick adaptation to the quickly
> > > changing GPU advancements. We can use such a structure to model the
> > > changing C++ tool advancements without waiting for the three year cycle.
> >
> > Two points to note here:
> > (1) Is an major-update cycle that's shorter than three years actually
> > best for consumption by the target audience (and when factoring in
> > implementers and their requirements / realities)?
> >
>
> Since compilers revision at a considerably faster rate than three years..
> And we will need to account for changes in those compilers.. Hence we need
> to cycle faster than three years.

I don't see the connection, sorry. What do you want to accomplish?
Different compilers have different release schedules, so you can't find
one frequency that fits all. Compilers also don't necessarily implement
all new proposals right in the cycle that they would fall in.

> > (2) Flexibility needs to have a clear goal. Do you want extensions to
> > be non-standard in the sense that we can't get consensus for them, or do
> > you rather want to make use of the TS process we already have?
> >
>
> Right.. The flexibility we need will come out as we work out the various
> parts of the problem. But at least for compiler options; which is my first
> task; we need some inherent room for vendor specific options that are
> documented and published. The TS process might be sufficient.. We'd have to
> evaluate how it fits.

What do you mean by "inherent room"?