Jump to page: 1 2
Thread overview
[Issue 17661] New isInputRange rejects valid input range
Jul 18, 2017
Vladimir Panteleev
Aug 03, 2017
Martin Nowak
July 17, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com

--- Comment #1 from Andrei Alexandrescu <andrei@erdani.com> ---
Can you try replacing the clause is(typeof((R r) => r.front)) with

is(typeof((R r) => r.front)) || is(typeof((R r) return => r.front))

?

If that works you may want to create a PR with it. Thanks!

--
July 17, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

--- Comment #2 from hsteoh@quickfur.ath.cx ---
Haha, I tried doing that but ran into another bug:

------
struct C {
    private S* impl;
}
struct S {
    bool empty;
    @property C front() return { return C(&this); }
    void popFront() { }

    pragma(msg, typeof((S r) return => r.front));
}
------

Compiler output (dmd -dip25 -dip1000):
------
test.d(10): Error: returning r.front() escapes a reference to parameter r,
perhaps annotate with return
_error_
------

Because of this, isInputRange still doesn't work, with your proposed change.

Apparently dmd fails to pick up the `return` annotation for some reason.  Which is actually rather strange, because:

-------
pragma(msg, typeof((int* r) return => r));
-------

prints:

-------
int* function(return int* r) pure nothrow @nogc return @safe
-------

so obviously the syntax is correct, and at least some of the time dmd is able to process it correctly.  I've no idea why it doesn't pick up the annotation and/or process it correctly when in the first code snippet above.

--
July 18, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--
July 19, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Andrei Alexandrescu from comment #1)
> is(typeof((R r) => r.front)) || is(typeof((R r) return => r.front))


I'm new to the "return" annotation, but is that right? I mean, I thought return was supposed to be an annotation on the parameter, not the function itself (which in this case is actually not a member function).

I would have expected:

(return R r) => r.front

--
July 28, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

--- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> ---
hsteoh, could you please submit those as a separate bug report for dmd and create a phobos PR using the simplest workaround you can find? That PR would close this bug, and the other bug will be for the compiler. Thanks!

--
August 03, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #5 from Martin Nowak <code@dawg.eu> ---
Well in, (R r) return => r.front, the return applies to the delegate context,
but you're escaping a reference to the argument.
What you want to check is `(return ref R r) => r.front`.

Also rewriting your front methods to a free functions helps understanding.

  C front(return ref S _this) { return C(&_this); }

Obviously allowing

  (R r) => front(r)

would return a dangling reference to the value parameter.

NB, if your front methods leaked a field of the range (e.g. a pointer), you'd need a `return scope` front methods, but the `(R r) => r.front` check is fine, since the parameter `r` isn't scoped, i.e. it might leak any pointer fields.

--
August 10, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #6 from hsteoh@quickfur.ath.cx ---
https://github.com/dlang/phobos/pull/5688

--
August 10, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

--- Comment #7 from hsteoh@quickfur.ath.cx ---
According to what Martin Nowak just said, there is no dmd bug, is that right? So we only need to fix Phobos.

--
August 14, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

--- Comment #8 from github-bugzilla@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/be9ad6a311a53e9ab8d2a8b69777b73d33b279c3 Fix issue 17661: isInputRange should work with .front that returns reference to parameter.

https://github.com/dlang/phobos/commit/6b460ab71750ae4d405ec392581d781a7d4f4e2a Merge pull request #5688 from quickfur/issue17661

Issue 17661: isInputRange should accept .front that returns reference to range merged-on-behalf-of: Petar Kirov <ZombineDev@users.noreply.github.com>

--
August 14, 2017
https://issues.dlang.org/show_bug.cgi?id=17661

github-bugzilla@puremagic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--
« First   ‹ Prev
1 2