http://d.puremagic.com/issues/show_bug.cgi?id=5354
--- Comment #5 from Denis Derman <denis.s...@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: -------