<p><br>
Le 3 sept. 2012 08:42, "Simen Kjaeraas" <<a href="mailto:simen.kjaras@gmail.com">simen.kjaras@gmail.com</a>> a écrit :<br>
><br>
> On Mon, 03 Sep 2012 08:34:33 +0200, Andrei Alexandrescu <<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>> wrote:<br>
><br>
>> we could add "in" to Tuple and get to write:<br>
>><br>
>> if (x in tuple("struct", "class", "union")) { ... }<br>
><br>
><br>
> if (x in tuple(1, new Foo(), "baa!") { ... }<br>
><br>
> Just kidding.</p>
<p>I was about to say the same, except not kidding :)<br>
I can see value in having this: finding if a value in a struct '.tupleof', for example. Or finding a range among a tuple of ranges, all of subtly different types and that cannot be put in an array.<br>
 I was imagining 'in' to return a boolean, but if you need it to return a possible value, then it can return a pointer to CommonType!(Ts) if this exists, or a pointer to Algebraic!(Types...).</p>
<p>Of course, that would also be a interesting place to use an Option!(T) type.</p>
<p> > tuple has the inconvenience that we don't know the values at compile-time.<br>
> If we did, we could take advantage of some cleverer tricks for fast<br>
> comparison. At the same time, it's a neat and logical solution.</p>
<p>We can try to get a fully-CT version, using template arguments, but I'm not sure that would be interesting.<br></p>
<p>People here are talking about sets, but does Andrei really have sets in mind? That has consequences if you want 'in' to return a pointer to a value.</p>
<p> </p>