On 13/06/15 21:05 +0300, Ville Voutilainen wrote:
Another round! The new patch
- makes sure not to change non-deduced parameters to deduced ones, and adds
tests for that.
- removes the name of the bool non-type template parameter for the 'concepts'.
- introduces shortcuts for making the use of th
On 8 June 2015 at 19:01, Ville Voutilainen wrote:
>> Yes, it should be uglified, thanks.
> Ahem, yes, actually removed since it's there only to be specialized.
Another round! The new patch
- makes sure not to change non-deduced parameters to deduced ones, and adds
tests for that.
- removes the na
On 8 June 2015 at 18:53, Ville Voutilainen wrote:
> On 8 June 2015 at 18:37, Martin Sebor wrote:
>> In the hunk below, should the sizes_match template parameter
>> be privatized (since it isn't part of the public interface)?
>> Or perhaps even removed if it's not used?
>
> Yes, it should be uglif
On 8 June 2015 at 18:37, Martin Sebor wrote:
> In the hunk below, should the sizes_match template parameter
> be privatized (since it isn't part of the public interface)?
> Or perhaps even removed if it's not used?
Yes, it should be uglified, thanks.
* include/std/tuple
In the hunk below, should the sizes_match template parameter
be privatized (since it isn't part of the public interface)?
Or perhaps even removed if it's not used?
Martin
@ -457,6 +457,73 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
};
+
+ // Concept utility fun
On 7 June 2015 at 11:33, Ville Voutilainen wrote:
>>> You use a lot: typename enable_if::type=true
>>> while the current code seems to favor: class=typename enable_if::type.
>>> I don't really care which one is used, but it is easier to read when the
>>> style is consistent through the library.
>>
On Sun, 7 Jun 2015, Ville Voutilainen wrote:
On 7 June 2015 at 11:12, Ville Voutilainen wrote:
Does the following code still compile with your patch?
struct A { int a,b; };
std::tuple a(3,4,{1,2});
No. :/ And we have no test for it.. I'll need to look at that.
Ahem, yes, this is because th
On 7 June 2015 at 11:12, Ville Voutilainen wrote:
>> Does the following code still compile with your patch?
>> struct A { int a,b; };
>> std::tuple a(3,4,{1,2});
>
> No. :/ And we have no test for it.. I'll need to look at that.
Ahem, yes, this is because the constructor that used to take _Elemen
On 7 June 2015 at 09:53, Marc Glisse wrote:
> Since the paper does not mention looking at _MoveConstructibleTuple or
> _ImplicitlyMoveConvertibleTuple here, could you add a comment explaining
> why that is needed?
Sure.
> Does the following code still compile with your patch?
> struct A { int a,
On Sun, 7 Jun 2015, Ville Voutilainen wrote:
- explicit
- constexpr tuple(const _Elements&... __elements)
+ template...>::value
+ && _TC<(sizeof...(_Elements) == sizeof...(_UElements)),
+_Elements...>::template
+ _Constr
This patch implements the so-called conditionally-explicit constructors
for tuple and pair, and also constrains the default constructors of tuple and
pair. The patch does not try to implement the part in N4387 that allows
constructing tuples from shorter packs than the tuple's element count,
I sugg
11 matches
Mail list logo
