[Issue 11080] assert(`string`) should be forbidden

[d-bugmail at puremagic.com]

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



--- Comment #11 from Maxim Fomin <maxim at maxim-fomin.ru> 2013-09-21 10:52:16 PDT ---
(In reply to comment #9)
> (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.

Assert("string") is a bug. There should be no discussion here. format("error")
is not an array literal, so it is irrelevant.

> 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!");

Ideally this should be documented and not be a subject to change. Anyway, one
can test ptr and length properties.

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

Assert("hello") is an uncoditional bug -  no need to calculate any chances.

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

Enforce is irrelevant.

> 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.

Built-in can not, but user-built can. This does not get into a conflict with
"if a built-in can do it, so should a user-built". (Arguments based on rules of
thumb coming from nowhere are hard to value). Contra point - dmd rejects some
potentially broken code, for example 'l' suffix for integer literal and
assignment in condition evaluation - which even is not necessarily a bug.

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