http://d.puremagic.com/issues/show_bug.cgi?id=3813
Andrei Alexandrescu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #23 from Andrei Alexandrescu <[email protected]> 2011-09-05 19:11:33 PDT --- (In reply to comment #22) > (In reply to comment #21) > > > more consistency is better than less consistency. > > Consistency is good when the situations don't change. But in our discussions > the conditions weren't invariant, because the range types (random access or > not) are different. This doesn't make sense, so I wouldn't know how to answer. Anyhow, first you wanted ';' to denote lazy vs. eager ranges. Now you want it to denote random access vs. other ranges - all irrelevant features to printing ranges. This forces someone who e.g. wants to parse some range to special-case things because the emitter of the string used a random-access range or not. This, again, makes no sense. For all I can tell you'd be happy as long as ';' vs. ',' differentiates _some_ aspect of a range, it doesn't really matter which. > The different separators is not an important feature, so if you aren't > interested I'll stop asking for it. It's just a cute little thing that I think > gives a little help. Please don't frame me as the arbiter. I'm just pointing out some nonsense. > > You keep on asking for arbitrary differentiation of kinds of ranges in their > > textual representation without any rationale. The burden is on you to > > justify > > the inconsistency, not on Kenji to justify consistency. > > The desire to tell apart lazy ranges from random access ranges comes from the > desire to give more information to the person that reads the textual output. > This is expecially useful in dynamically typed languages, but it's useful in D > too, because you use "auto" definition, template type values, and generally > reading textual outputs it's not always easy to know what part of the printout > is generated by a specific writeln. So you want differentiation, it doesn't matter on what feature. Numeric vs. non-numeric seems fair game too. > Currently D allows implicit casts between float/double/real. But you can't > implicitly cast an int to float. So while float and double are two different > types just as int and double are two different types, in D double and real are > less different than a double and an int. So the D definition of "different > type" is not fully binary, it's a bit fuzzy. No, it's quite binary. Two types are identical or not. > (It can be argued that a good textual representation of floats/reals has to > contain a leading "F"/"L". I think this is a bit overkill, but it's not so > bad.) > > > > One paragraph below (!) you are asking for the exact opposite: less type > > differentiation. You want to change > > > > > Tuple!(int,string)(1, xx) > > > > to > > > > > tuple(1, "xx") > > > > Both changes have pros and cons, but there's no guiding rationale behind > > them. > > There is a rationale: I'd like What one likes is not rationale. > the textual representation to be as informative > as possible, and possibly to be "invertible" too (so "unprinting" it gives > back > the original value or data structure), unless this goes too much against other > practical considerations (like output space, output readability, etc). But in the same breath you propose tuple(1, "hello") instead of Tuple!(int, string) although it could originate from a Tuple!(short, char[]). Your own requests are dissonant with your own desiderata. To be frank, you quite literally don't know what you want. Why are we spending our valuable time on this? > Writing on default a double as 2.0 instead of 2 is good because it tells me > that I have printed a value of one of the floating point types > (float/double/real or some other library defined FP value). In several > situations it's useful to know if a value is integral or not. It's also bad because it takes more space. > Printing a tuple like: > > Tuple!(int,string)(1, xx) > > Is bad because the second argument is not what you see in the code, so if you > "unprint" it you get an error (unless you add a special case for this > situation, but this is not good and it doesn't scale). > > (Doing the same for a TypeTuple is acceptable, in my opinion.) > > So this is a better textual representation: > > Tuple!(int,string)(1, "xx") I agree that printing a tuple should produce unambiguous representation of its fields, but that's different from your request that the type of Tuple is replaced with the word "tuple". > Currently if you print an array of strings you get: > > ["xx", "yy"] > > Because this allows unprinting, is more readable, etc. For consistency with > string array printing, I'd like tuples to do the same (while TypeTuples are > very different from arrays). So now you list unprinting as a desideratum yet it's only seconds after you asked for making that gratuitously difficult by using ';' vs. ',' on some arbitrary criterion. > Now think about an array of tuples, if you print one of them you get something > like: > > [Tuple!(int,string)(1, "aa"), Tuple!(int,string)(2, "bb"), > Tuple!(int,string)(3, "cc"), > Tuple!(int,string)(4, "dd"), Tuple!(int,string)(1, "ee"), > Tuple!(int,string)(1, "ff"), > Tuple!(int,string)(1, "gg"), ...] > > Here in my opinion there is too much noise, most of the space is used by > redudant things. This is why I have suggested to print tuples, when they are > inside a collection, in a shorter way: > > [tuple(1, "aa"), tuple(2, "bb"), tuple(3, "cc"), > tuple(4, "dd"), tuple(1, "ee"), tuple(1, "ff"), > tuple(1, "gg"), ...] > > Or even (but this can't be unprinted, so this is probably eccessive): > > [(1, "aa"), (2, "bb"), (3, "cc"), (4, "dd"), (1, "ee"), (1, "ff"), (1, "gg"), > ...] > > > On the other hand if I print a single tuple, outside of collections, then > showing the full typing is usually acceptable: > > Tuple!(int,string)(1, "xx") > > > In arrays of FP values the ".0" adds add just two chars and only to numbers > that don't already have one or more decimal digit. So the added ".0" doesn't > add too much noise (unlike adding "Tuple!(int,string)"). Quite honestly I think the noise is in this discussion. I am closing this report. Sorry. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
