http://d.puremagic.com/issues/show_bug.cgi?id=11080
--- Comment #9 from monarchdo...@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: -------