From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-07-20 12:50:39
At 12:40 PM 7/20/2001, Darin Adler wrote:
>On Friday, July 20, 2001, at 09:18 AM, David Abrahams wrote:
>> From: "Beman Dawes" <bdawes_at_[hidden]>
>>> I think that Boost Coding Guidelines should be accepted, but subject
>>> refactoring into separate "Requirements" and "Guidelines" documents.
>>> refactoring should include material from the current "Library
>>> and Guidelines" page, http://www.boost.org/more/lib_guide.htm, and
>>> one or two other current pages.
>> How will we decide which are requirements and which are guidelines?
>My two cents:
>By default make everything a guideline.
That's an interesting approach. But there should be at least one
exception: Anything which is already a requirement in
http://www.boost.org/more/lib_guide.htm stays a requirement. There are
only four coding requirements currently, all having to do with portability.
It should be possible to promote a few or the guidelines to be requirements
if they are non-controversial. For example, I'd like to see "ISO Standard
C++" elevated to a requirement, although even for that we would want to add
a caveat allowing non-standard extensions be used in alternate
> Convert the entire document into
>the guidelines document. Then as time allows, promote things to be
>requirements. You and Beman can decide whether formal review is required
>or not for your initial requirements documents with your best judgement
>and depending on how many requirements you end up with and whether they
>are things that were controversial in the guidelines review process.
>The requirements will presumably be a small set compared with the
>extensive set of guidelines. We can always downgrade a requirement to a
>guideline after the fact, if we decide it was a mistake.
>The issues are not the same as with code, where making a change after the
>library is accepted can easily result in incompatibilities for people
>upgrading to a new version of the Boost libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk