static arrays becoming value types

language_fan foo at bar.com.invalid
Wed Oct 21 10:52:55 PDT 2009


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)}




More information about the Digitalmars-d mailing list