On Mon, 24 Sep 2012 16:50:47 +0200
"foobar" <f...@bar.com> wrote:
> On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky
> wrote:
> > On Mon, 24 Sep 2012 10:56:40 +0200
> > Jacob Carlborg <d...@me.com> wrote:
> >
> >> On 2012-09-24 07:01, Nick Sabalausky wrote:
> >>
> >> > I think one of us is missing something, and I'm not entirely
> >> > sure
> >> > who.
> >> >
> >> > As I explained (perhaps poorly), the zero- and one-element
> >> > tuples
> >> > *would still be* tuples. They would just be implicitly
> >> > convertible
> >> > to non-tuple form *if* needed, and vice versa. Do you see a
> >> > reason
> >> > why that would *necessarily* not be the case?
> >>
> >> Would that mean you could start doing things like:
> >>
> >> int a = 3;
> >> int b = a[0];
> >>
> >> That feels very weird.
> >>
> >
> > No, because there's nothing typed (int) involved there. But you
> > could do
> > this:
> >
> > int a = 3;
> > (int) b = a;
> > a = b;
> >
> > Or this:
> >
> > void foo((int) a)
> > {
> > int b1 = a[0];
> > int b2 = a;
> > }
> > int c = 3;
> > foo(c);
>
> What's the point than?
> here's equivalent code without this "feature":
>
> int a = 3;
> (int) b = (a); // explicitly make 1-tuple
My understanding is that *can't* be made to work in the general
case (without those ugly trailing commas) because, in general, how's the
compiler supposed to know if (a) is a parenthesis expression or a tuple
literal?
That's exactly what my suggestion was attempting to solve: The '(a)'
would be a paren expression (with type 'int') just as right now, but
then in order to make it still assignable to '(int)', just as you've
done, we say "Ok, you can assign an 'int' to an '(int)' and it
implicitly converts."
All the stuff I said earlier about one-element tuples being
conceptually the same as non-tuples was just my way of explaining that
it's not too much of an unintuitive inconsistency if we allow implicit
packing/unpacking of one-element tuples, but not two-or-more-element
tuples.
