Subject: Re: [boost] Asciidoc, an alternative for documentation
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-10-09 17:43:20
> Would this be helped by characterizing Expected/Outcome as something
> like ... "to be used as a resultant type by an operation which might
> fail" or some such?Â This would make all the arguments about what
> happens on assignment out of scope.
Thanks to your suggestion Robert to make Outcome a simple struct,
assignment is now uncontroversial.
Â Of course now people would say the
> scope is too narrow.Â etc.....Â The "reviews" of these ideas tend to try
> to generalize them - generally a good thing - but not always.Â Some
> times the attempt to reconcile all the requested features results in a
> watering down of the original good idea.
The v2 object is very considerably more simple than the v1 object. You
may remember I converted over an existing codebase from v1 to v2, and
for the most part it went okay.
Expected is also much simpler than it was last May. Vicente took many of
the same simplifying steps to Expected as I did to Outcome from the review.
> When a simple idea like
> Outcome/Expected generates documentation of more than 4? pages, it's
> time to step back and ask oneself whether we've lost our and turned our
> original elegant idea into a monstrosity.
I know what you're saying. But when very senior members of WG21 seem to
also need more than twenty pages of hand holding tutorial for a class
which carries T|E and does nothing else, I think it's more a case of
that the simpler and more fundamental the object, the vastly more
documentation explaining it becomes needed.
As an analogy, you may remember the "variant wars" which went on for
nearly forever. A very simple, very well understood, object often
generates the strongest opinions and people absolutely convinced that
the other is wrong. Proof required to convince people thus rises
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk