Boost logo

Boost :

From: Mike (mike.dev_at_[hidden])
Date: 2020-09-23 09:03:04


> Gesendet: Mittwoch, 23. September 2020 um 09:53 Uhr
> Von: "Hans Dembinski via Boost" <boost_at_[hidden]>
>
> > On 23. Sep 2020, at 08:54, Spencer Collyer via Boost <boost_at_[hidden]> wrote:
> >
> > Maybe use 'enhanced' (or 'enhanced_by') rather than 'required'. Or 'added_value'?
>
> +1 for 'enhanced'. Apart from the minimum, it is useful for lib authors to advertise that they support newer standards as well.

Please keep it simple:
The minimum required standard has an immediate value for tooling and is easily understood by the user:
"If you want to use the library, you have to enable that mode" / "If my toolchain only supports
c++XX, I should not try to build/use this lib".

Enhanced on the other hand doesn't tell me anything, except probably that there is at least
one macro/precompilation branch that evaluates differently in different modes.
Is a library already enhanced in c++14, if more functions become constexpr? Does a lib that
is enhanced_by c++17 have to provide overloads for std::string_view? Is a library enhanced
by c++XX, if the interface/cababilities remain the same, but the implementation is more
efficient/needs fewer boost-internal dependencies? What about libs that use another lib
that is enhanced by c++XX, but the lib itself doesn't care directly? Would boost config
count as enhanced?
Imho, "enhanced_by" is only useful when accompanied by further information detailing,
what changes, so I'd keep that information in the readme/documentation.
Also - as far as advertising is concerned - it is not like I (as human) am usually
looking at meta at all, if I want to know something about a library. I'm looking at the
readme and the documentation - of course that last point might be specific to myself
and not representative.

best

Mike

>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk