Boost logo

Boost :

Subject: Re: [boost] std::optional<T>
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2013-04-22 13:02:43


On 22-Apr-13 1:52 PM, Andrey Semashev wrote:
> On Monday 22 April 2013 12:45:58 Fernando Cacciola wrote:
>> On 22-Apr-13 12:09 PM, Mathias Gaunard wrote:
>>> On 22/04/2013 15:05, Fernando Cacciola wrote:
>>>> On 22-Apr-13 9:37 AM, Nathan Crookston wrote:
>>>>> Fernando Cacciola wrote:
>>>>>> Hi People,
>>>>>>
>>>>>> I'm pleased to announce that thanks to the outstanding effort of
>>>>>> Andrzej
>>>>>> Krzemienski who wrote the standard papers, and Ville Voutilainen who
>>>>>> champion it during the meetings, we now have std::optional<T> in C++14!
>>>>>
>>>>> Great news! I'm almost scared to ask, but what did the committee decide
>>>>> concerning optional<T&>?
>>>>
>>>> LOL, I knew people would ask.
>>>> Well, they decided to drop it from C++14.
>>>
>>> That's not what I remember.
>>>
>>> I thought that what was said is that optional<T&> didn't need to be
>>> specialized,
>>
>> That's technically correct.
>>
>> So I should have said that our proposed specialization for T& was dropped.
>
> First, congratulations! I'm happy to see this component is making its way into
> the standard.
>
:)

> Second, if I understand correctly, without specializing optional for
> references, optional<T&> will be suboptimal (i.e. it will essentially be a
> pointer and a bool instead of just a pointer). Why not requiring this
> optimization?
>
AFAICT, you cannot require any optimization for a library component in
the STD. At most you can add a note suggesting this or that implementation.

In any case, have in mind that an implementation would be free to store
just a pointer in the case of <T&> provided it conforms to the
specification.

The "proposal for references" that I mentioned is not intended to
accommodate implementations but to explicitly specify special semantics
that I think are important and which do not directly derive from the
general case.

Best


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