[Issue 5550] std.range.enumerate()

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Jan 17 02:10:00 PST 2014


https://d.puremagic.com/issues/show_bug.cgi?id=5550



--- Comment #15 from Jakob Ovrum <jakobovrum at gmail.com> 2014-01-17 02:09:51 PST ---
(In reply to comment #14)
> (In reply to comment #13)
> 
> > As far as I can tell, this cannot be implemented; it is an error that the
> > compiler accepts use of `ref` in foreach over a range that doesn't have
> > assignable elements. It is a problem shared with many other higher order
> > ranges.
> 
> I see. Instead of disallowing this quite useful feature, are there plans to
> improve the language to allow this feature in library code?

I have no idea. Maybe it's possible in the current language to implement a
`RefTuple` or something, but it's outside the scope of `enumerate`.

> > I would also change [1 .. $] to .drop(1), but it is a minor stylistic issue.
> 
> Yes, in my code in a situation like that I'd like to use .dropOne, but I have
> used a simpler slicing because it's "simpler", it doesn't introduce more ranges
> from Phobos :-) When you explain one function in the documentation, you want to
> minimize the number of other functions used.

That is a good point, but `dropOne` is in the same module and a fairly basic
algorithm, so I think it's more important to propagate idiomatic code. It
should be fairly intuitive to understand even without foreknowledge of what
`dropOne` does. Note that DDoc underlines `enumerate` in the examples, so it
tends to be fairly readable even when "noise" such as other algorithms are
used. Perhaps DDoc supports hyperlink referencing in example code to further
ease the issue.

> > I still recommend you post on Github, it's likely that it will get more review
> > and comments there. Also, it's only right that implementation comments go to
> > the implementation proposed on Github, with the issue tracker dedicated to the
> > problem statement in general...
> 
> From my limited experience in commenting on GitHub, I've seen that currently
> the linear threads in those GitHub pages are even less handy than the linear
> threads here in Bugzilla, especially when the comments become longer than 2-3
> lines of normal text. Here you can also add attaches.

Github line comments are a pretty good substitution for threaded comments.

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


More information about the Digitalmars-d-bugs mailing list