https://issues.dlang.org/show_bug.cgi?id=15459

Simon Na. <eiderdaus@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|stdio.byLine.each!(map!some |stdin.byLine.each!(map!some
                   |func) compiles, fails to    |func) compiles, fails to
                   |link with ld                |link with ld

--

https://issues.dlang.org/show_bug.cgi?id=15459

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petar.p.kirov@gmail.com

--- Comment #1 from ZombineDev <petar.p.kirov@gmail.com> ---
When you're iterating any kind of string (char, wchar or dchar based) the element type is always dchar. This special case for narrow strings (UTF-8 and UTF-16) is also known as UTF autodecoding. You can see this for yourself if you change `somefunc` into a template and add a pragma statement to make the compiler emit an information message about the type of `c` for each instantiation of the function:

auto somefunc(C)(C c)
{
    pragma (msg, C);
    return c;
}

See also: http://dlang.org/phobos/std_range_primitives.html#.ElementType, http://dlang.org/phobos/std_range_primitives.html#.front and http://dlang.org/glossary.html#narrow strings

This is still a valid bug report, because the compiler should refuse to compile this code.

--

https://issues.dlang.org/show_bug.cgi?id=15459

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid
           Hardware|x86_64                      |All
                 OS|Linux                       |All
           Severity|normal                      |major

--

https://issues.dlang.org/show_bug.cgi?id=15459

--- Comment #2 from Simon Na. <eiderdaus@gmail.com> ---
Thanks for the thorough explanation!

--

https://issues.dlang.org/show_bug.cgi?id=15459

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dlang-bugzilla@thecybershad
                   |                            |ow.net
         Resolution|---                         |INVALID

--- Comment #3 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
The example presented is invalid, as the parameter of each is not expected to return anything, and map is lazy and by itself does not mutate global state (is pure if its predicate is). It also doesn't compile any more in the latest version of D.

I'm closing this for now, but please reopen if you can provide a working practical example.

--

https://issues.dlang.org/show_bug.cgi?id=15459

--- Comment #4 from ZombineDev <petar.p.kirov@gmail.com> ---
Vladimir, shouldn't this bug be closed as "WORKSFORME", as the bug was that the compiler accepted the invalid example in the first place?

--

https://issues.dlang.org/show_bug.cgi?id=15459

--- Comment #5 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
(In reply to ZombineDev from comment #4)
> Vladimir, shouldn't this bug be closed as "WORKSFORME", as the bug was that the compiler accepted the invalid example in the first place?

Well, the code wasn't technically invalid, just nonsensical. It stopped working after this PR:

https://github.com/dlang/phobos/pull/5148

I'm not sure if that behavior change was intentional either, hence my comment there.

There is also no practical difference between INVALID and WORKSFORME in practice, I think.

--

https://issues.dlang.org/show_bug.cgi?id=15459

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |ag0aep6g@gmail.com
         Resolution|INVALID                     |---

--- Comment #6 from ag0aep6g@gmail.com ---
(In reply to Vladimir Panteleev from comment #3)
> I'm closing this for now, but please reopen if you can provide a working practical example.

Reduced accepts-invalid:

----
enum e = is(typeof(map()));

struct MapResult()
{
    this(char[] a) {}

    char front()
    {
        dchar d;
        return d; /* should fail compilation */
    }
}

void map()()
{
    auto mr = MapResult!()([]);
}

void main()
{
    map();
}

--

https://issues.dlang.org/show_bug.cgi?id=15459

--- Comment #7 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
(In reply to ag0aep6g from comment #6)
> (In reply to Vladimir Panteleev from comment #3)
> > I'm closing this for now, but please reopen if you can provide a working practical example.
> 
> Reduced accepts-invalid:

This is not a valid reduction because .front is never called. The compiler seems to be skipping semantic analysis of uncalled functions here to avoid forward reference issues: https://github.com/dlang/dmd/pull/2851

--

https://issues.dlang.org/show_bug.cgi?id=15459

--- Comment #8 from ag0aep6g@gmail.com ---
(In reply to Vladimir Panteleev from comment #7)
> This is not a valid reduction because .front is never called.

front is never called in the original code either.

> The compiler
> seems to be skipping semantic analysis of uncalled functions here to avoid
> forward reference issues: https://github.com/dlang/dmd/pull/2851

So the invalid front is supposed to be accepted (if it's never called)? Then I suppose the accepts-invalid aspect of this issue is WONTFIX.

But it should link then, no?

--