[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



--- Comment #5 from Denis Derman <denis.spir at gmail.com> 2010-12-15 10:45:23 PST ---
(In reply to comment #2)
> My thoughts:
> 
> 1. Using Range interface for formatting classes and structs is a good thing and
> should stay.

Why? Please criticise my arguments above, especially:
* Formatting a type exactly according to the builtin default format of an array
has no reason to be a common case. Note that a range interface is only _one
aspect_ of a type.
* Even in this case, writing a 3-4 line toString is not a big deal.
* Introducing default array-like formatting for ranges also introduces semantic
and implementation issues & complication of the code base. 

> 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.

No! _Default_ range interface formatting cannot have priority over
_explicitely_ defined formatting by the programmer. This is a serious
conceptual bug. A programmer who defines toString *wants* it to be used, else
why would one define it at all? You take here precedence considerations upside
down.
[See also (*) below.]

> 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.

Agreed. In addition to my example above (of a string type behaving like in most
high-level languages): common forms of link-list, tree, graph hold nodes which
themselves are lists, trees, graphs.
They must be properly considered as ranges. This special case needs not be
detected, I guess. The bug is not due to their recursive nature (else we could
never write out a tree ;-), but lies somewhere in D's current writing algorithm
for ranges (*). Indeed, the recursive call should end some day, namely on
terminal nodes...
Actually, in such cases of recursive range, I would simply recommand toString
to be defined [because leaf nodes must end formatting recursion, again see
(*)]. And default range formatting should neven be used.

> 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.

(*) The bug seems to be similar to left-recursive PEG-parsing: when I try to
write out a struct object implementing the input range interface, I get an
"infinite" series of '[', then segfault. The error seems to be writing out the
opening character '[' for each nesting level before having computed the whole
string at this level -- which can be empty ot otherwise end the recursion.
Actually, more fondamentally, the error is precisely caused by ignoring the
user-defined toString that would end recursion by a special, non-recursive,
form for terminal elements (leaves). One more reason to respect
programmer-defined toString instead of shortcutting it.

Denis

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