Wed, 21 Oct 2009 16:54:22 +0000, language_fan thusly wrote: > Wed, 21 Oct 2009 10:48:34 -0500, Andrei Alexandrescu thusly wrote: > >> language_fan wrote: >>> Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote: >>>> My issue was that all your example _showed_ was nominal typing. >>>> Though I didn't mention it by name, I did mention that if SOL tuples >>>> had structural typing, it might would be a different story. (Well, >>>> until/if opImplicitCast was implemented, as it would allow for >>>> structural typing.) >>> >>> Why do you insist on using nominal typing for tuples and the library >>> defined "literal". If I want plain old tuples without any kind of type >>> name, why should I care about extra hand waving needed to make it >>> work. >> >> I'm late in this dialog, but I'm not seeing an impediment here. What >> does it matter to you that tuples actually have a name vs. not having a >> name at all? > > Using tuples in D is a major pain in the ass. In fact it has been made > so hard that people start avoiding the feature like plague. I wrote some > test code to reveal how inconsistent their semantics are. Note that you > need the built-in tuples for some stuff, like assigning and mixed value/ > type tuples. Stuples can only be used as values and when the auto- > flattening is not desired. > >>>> STARTS HERE
Even though not being an expert in Python (have not really used it), as an experiment I managed to successfully port the examples in 2 minutes without any kind of problems. a = (1,1) e1 = a[0] print a def retTest(): return (1,1) (d,e) = (10,20) (d,_) = (10,20) (d,b) = (1, retTest()) a3b = [ (1,1), (2,2) ] a7 = { (1,1) : 5 } a8 = { 5 : (1,1)}