Proto for Boost mailing list page: Re: [proto] Proto v5

Subject: Re: [proto] Proto v5
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2013-06-15 22:19:09

On 15/06/2013 10:59 p.m., Eric Niebler wrote:
> On 13-06-15 03:40 PM, Agustín K-ballo Bergé wrote:
>> On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote:
>>> On 14/06/2013 11:06 p.m., Eric Niebler wrote:
>> - Some specific uses of Proto actions in constant expressions fail. GCC
>> reports an ambiguity with ref-qualifiers in the following scenario:
>>
>>      struct foo
>>      {
>>          int& bar() &
>>          { return _bar; }
>>          //~ int&& bar() &&
>>          //~ { return static_cast<int&&>(_bar); }
>>          constexpr int const& bar() const &
>>          { return _bar; }
>>          constexpr int const&& bar() const &&
>>          { return static_cast<int const&&>(_bar); }
>>
>>          int _bar;
>>      };
>>
>>      foo().bar();
>>
>>    For that to work correctly, the 4 overloads need to be provided.
>
> Huh. According to the standard, or according to gcc? I won't work around
> a bug in a compiler without filing it first.

I do not know, this little experiment has got me re-reading the standard 
back and forth, but I am not that fluent in standardeese. I'm still 
researching this and a few other of the issues.

>> This,
>> in turn, means that non-const rvalues (?) cannot be used in constant
>> expressions since constexpr implies const (in C++11, not anymore in
>> C++14). Anyway, this is more than I can digest at the moment.
>>
>> (*) the bit failing to compile is a use of Proto actions as a constant
>> expression [the `omg` case at everywhere.cpp], due to the issue with
>> ref-qualifier overloads.
>
> I see you included all of these fixes in your one pull request. I'll
> need to go through this carefully and file compiler bugs where
> necessary.

I did not, or if I did it was unintentional. I only wanted to submit the 
first change I did, the one that fixes the duplicated constexprs. That's 
the single one I'm confident enough that has to be applied. Alas, the 
last change I did silences a GCC warning, so that one is another good 
candidate (after refactoring to your coding style). The others probably 
won't fit your coding style anyways, plus some are even incorrect and 
further reverted/fixed. They are only intended to be a guide of what has 
to be changed to please GCC.

> I also want to use BOOST_WORKAROUND if we actually include
> any temporary workarounds in the code. I say "temporary" because I have
> every intention of ripping out all workarounds once the bugs actually
> get fixed. I intend to keep this code as clean as possible.
>

I would appreciate if we could discuss (off-list if appropriate) all 
these changes I've done as you go through them, whenever you have the 
time. I am particularly interested in determining whether the code is 
standard conforming, or whether they are the result of bugs in either 
GCC or Clang.

> A million thanks for your work. It's a huge help.
>

My pleasure. This has been a productive learning experience for me (one 
that has not yet ended I hope).

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com