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