Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-02-14 08:05:32

Olaf van der Spek wrote:
> On Mon, Feb 13, 2012 at 9:51 PM, Andrzej Krzemienski
> <akrzemi1_at_[hidden]> wrote:
> > Certainly, there ways to make the output of optional
> > configurable.
[snip]
> > However, when it comes to proposing stuff in front of the ISO
> > committee, there is one other factor, which I failed to
> > mention yet. It is the "fragility" of the process. I am
> > concerned that if anything turns out to be controversial, the
> > whole Optional would be at risk of being rejected. This
> > might be an exaggeration (I have never gone through the
> > process of proposing something and then pushing it through),
> > but Optional has already been proposed by Fernando
> > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1878.htm)
> > and rejected; primarily for two things: operators -> and *
> > and the semantics for optional reference assignment (see
> > http://lists.boost.org/Archives/boost/2005/10/95079.php). I
> > would much like to avoid the situation where Optional (which
> > I believe is very useful to wide variety of programmers)
> > would be rejected because of one additional, however tiny,
> > controversy of streaming operator.

I agree with being conservative to ensure its inclusion, but there may be a way to get both.

> I think the safe option is to not include it. Same for
> references. What's the problem with the ptr interface? Seems
> fine with me.

One proposal can be for the no I/O, no reference version.  Another proposal could extend that with I/O.  Yet another could extend it with reference support.  That would permit the first proposal to be accepted, even if the others are rejected.  I think it is also reasonable to make I/O and reference support optional additions to the core of a single proposal.

Obviously, I/O can be defaulted and made customizable.  Deciding on widely useful defaults may not be easy, but customization does permit choosing alternatives.  The easiest customization is, of course, a traits class.

Reference support, with some assignment policy, can be added by a wrapper type.  "optional_with_references", say, can do everything the normal optional class does plus add support for references.  That's not as pretty, perhaps, but there would, then, be no question as to the behavior in a given context.  Indeed, you could have two variants of the wrapper to give both assignment protocols, thereby removing all confusion.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.