http://d.puremagic.com/issues/show_bug.cgi?id=11080

           Summary: assert(`string`) should be forbidden
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: temtaime@gmail.com


--- Comment #0 from Temtaime <temtaime@gmail.com> 2013-09-20 15:22:29 PDT ---
Subj.

assert(`something going wrong`);

Compiles and never fails.
Sometimes it makes a mistake.

IMO assert should be:
void assert(bool, string = ``);

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com


--- Comment #1 from monarchdodra@gmail.com 2013-09-21 01:50:42 PDT ---
Not sure it's valid: What you are seeing is basically a dynamic array implicitly decaying to its pointer / boolean in a conditional clause. Some (myself included) judge this feature should be deprecated anyways.

For example, this would be a "legit" use of "assert(string)":
string s;
assert(s);

So, overall, I think you are seeing a "special" case of a more generic problem, eg:

while ("hello") ...
if ("hello") ...
auto k = "hello" ? ... : ... ;

All of the above I judge ambiguous.

I couldn't find any relevant entries about this, but the "issue" *has* been beaten to death on the forums: http://forum.dlang.org/thread/bwgnbflygowctlisistg@forum.dlang.org

Enjoy :)

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim@maxim-fomin.ru


--- Comment #2 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-09-21 03:01:19 PDT ---
I think banning assert("Any array literal"); makes sense as it is always true and may hide programmer error of forgetting to place some condition before string. Empty array literal is a special case - it is currently implemented as pair null + 0 size.

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080



--- Comment #3 from Temtaime <temtaime@gmail.com> 2013-09-21 04:26:39 PDT ---
D allows implicit convertion from an array to bool ? It's... strange.

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #4 from bearophile_hugs@eml.cc 2013-09-21 04:38:30 PDT ---
(In reply to comment #3)
> D allows implicit convertion from an array to bool ? It's... strange.

Right, I think this bug report should be closed. The design bug to fix is to refuse the implicit convertion from a dynamic array to bool (and perhaps there is already a bug report open on that).

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080


Temtaime <temtaime@gmail.com> changed:

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


--- Comment #5 from Temtaime <temtaime@gmail.com> 2013-09-21 04:39:26 PDT ---
Okay. Then it's my mistake.

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080



--- Comment #6 from bearophile_hugs@eml.cc 2013-09-21 05:15:43 PDT ---
The bug report is mine, you could vote it:

http://d.puremagic.com/issues/show_bug.cgi?id=4733

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


--- Comment #7 from bearophile_hugs@eml.cc 2013-09-21 05:18:39 PDT ---
(In reply to comment #5)
> Okay. Then it's my mistake.

On the other hand Issue 4733 is opened since three years, so I don't know if Walter & Andrei agree with it. If Issue 4733 gets refused then adding a warning or error for assert("something") is a good idea. So I thin it's better to keep this open until there's an official answer on Issue 4733.

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080



--- Comment #8 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-09-21 08:23:52 PDT ---
(In reply to comment #7)
> (In reply to comment #5)
> > Okay. Then it's my mistake.
> 
> On the other hand Issue 4733 is opened since three years, so I don't know if Walter & Andrei agree with it. If Issue 4733 gets refused then adding a warning or error for assert("something") is a good idea. So I thin it's better to keep this open until there's an official answer on Issue 4733.

This may be a separate issue. For example, the problem you pointed out can be solved by rewriting array conditional evoluation to return length and not ptr which still technically allows to write assert(""). In such case this isssue still has some value.

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

http://d.puremagic.com/issues/show_bug.cgi?id=11080



--- Comment #9 from monarchdodra@gmail.com 2013-09-21 10:31:41 PDT ---
(In reply to comment #8)
> This may be a separate issue. For example, the problem you pointed out can be solved by rewriting array conditional evoluation to return length and not ptr which still technically allows to write assert(""). In such case this isssue still has some value.

I don't really such much value in banning string literals in asserts. For starters, it is awfully specific. Second, I have trouble seeing why literals get such a special treatment, when "assert(format("error"))" is just as "wrong". It'd be creating new rules to catch an error that virtually never happens anyways, and catches it un-reliably to boot.

Finally, a valid use case I can see would be a user wanting to check that an
empty string *actually does* implicitly evaluate to non null:
static assert ("", "Error! string to bool evaluation rules have changed!");

Chances are `assert("hello")` was wrong useage yes, but I think it hardly warrants new language rules...

...rules you wouldn't be able to apply to normal functions. For example an "enforce" that refuses array literals. Can't happen.

A good rule of thumb is that if a built-in can do it, so should a user-built. This would not be the case for this new rule.

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