[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5354


Nick Voronin <elfy.nv at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elfy.nv at gmail.com


--- Comment #2 from Nick Voronin <elfy.nv at gmail.com> 2010-12-15 09:59:49 PST ---
My thoughts:

1. Using Range interface for formatting classes and structs is a good thing and
should stay.

2. There is a conflict of priority between using toString and iterating through
a Range. It's worse for classes where toString is always present and can't be
used to deduce programmer's intent. IMHO it's more important to keep things
uniform, than to make best guess in every case, so iterating through range must
have priority over using toString. At least unless there is more direct way to
tell what's programmer's intent about default formatting of struct or class.

3. Range with (ElementType!T == T) must be either detected throughout all
library as a special case or not detected as a Range at all. I'm under
impression that algorithms (not just formatting routines) expect that front()
yields some value. This value /may/ be another Range, there may be hierarchical
structures containing Ranges of Ranges, yet this hierarchy is expected to be
finite, so full traversal of it is possible. I expect there are more trouble
waiting to happen with Ranges like that if they go generally undetected. I may
be wrong here, it would be great to have someone with knowledge of both current
practice and original intent clarify this matter.

4. 
> Also, the online doc does not hold template constraints, so that it is not possible to determine which one is selected in given situations.
+1!

5. attached a testcase of various combination (class|struct, normal
range|recursive range|no range, has override for toString|no override toString)
and patch which makes all cases compile and print uniform output for struct and
class. For this case changes are really very simple, constraints still look
manageable, and one can still enjoy specific formatting for ranges.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------