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

Jack Stouffer <jack@jackstouffer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid

--

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

--- Comment #1 from Kenji Hara <k.hara.pg@gmail.com> ---
Although the OP code is legitimate from the D grammar spec, there's not yet proper definition/implementation for the semantic analysis.

I'm not sure how compiler should behave with:

deprecated(a.foo() ~ a.bar()) module a;

string foo() { /* some CTFEable code 1 */ }
string bar() { /* some CTFEable code 2 */ }

----

Note that if we replace module with struct:

deprecated(S.foo) struct S   // line 1
{
    static foo() { return "hello"; }
}
alias P = S*;  // line 5


Current compiler prints:

test.d(1): Deprecation: struct test.S is deprecated
test.d(5): Deprecation: struct test.S is deprecated - hello

The use of S in custom message expression exposes incompletion of semantic analysis process. It's bad behavior.

--

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

--- Comment #2 from Jack Stouffer <jack@jackstouffer.com> ---
It could at least be made to work with string literals and manifest constants, right?

--

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

--- Comment #3 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to Jack Stouffer from comment #2)
> It could at least be made to work with string literals and manifest constants, right?

I think it's not good to implement vulnerable behavior. It would just bloat compiler maintenance cost.

By the way, do you have a concrete situation you would like to use contatenation, manifest constant, or other compile time constructed message for module deprecation?

--

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

jiki@red.email.ne.jp changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jiki@red.email.ne.jp

--- Comment #4 from jiki@red.email.ne.jp ---
One could simply put pragma message in that module.

module a;

pragma(msg, __FILE__,"(",__LINE__,"): this module is deprecated");

--

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

--- Comment #5 from Jack Stouffer <jack@jackstouffer.com> ---
(In reply to Kenji Hara from comment #3)
> (In reply to Jack Stouffer from comment #2)
> > It could at least be made to work with string literals and manifest constants, right?
> 
> I think it's not good to implement vulnerable behavior. It would just bloat compiler maintenance cost.

But this is already the behavior for everything but module declarations:

-----
struct A
{
    deprecated(""~"") int a;
}

void main()
{
    A s;
    s.a = 4;
}
-----

$ dmd -run test.d

Deprecation: variable test.A.a is deprecated -

> By the way, do you have a concrete situation you would like to use contatenation, manifest constant, or other compile time constructed message for module deprecation?

Yes, in Phobos we are trying to enforce Phobos style guides via dscanner, and we need this in order to make every line in Phobos less than 120 characters.

--

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

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pro.mathias.lang@gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #6 from Mathias LANG <pro.mathias.lang@gmail.com> ---
Sometime I look at the timing, and I think we're doing a really bad job at
marketing our awesome features. The fix for this was merged in February 2016,
so 3 months before this bug report was open. Fixed by:
https://github.com/dlang/dmd/pull/5302
Marking as duplicate of the original issue.

*** This issue has been marked as a duplicate of issue 12954 ***

--