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