Feature request: assert expressions should live inside version(assert)

Denis Shelomovskij verylonglogin.reg at gmail.com
Sun Jul 7 06:33:18 PDT 2013


07.07.2013 17:12, Tommi пишет:
> On Sunday, 7 July 2013 at 12:30:28 UTC, Andrej Mitrovic wrote:
>> On 7/7/13, Tommi <tommitissari at hotmail.com> wrote:
>>> Sometimes you need to have some extra data to check against in
>>> the assert expression. That data isn't needed in release mode
>>> when assertions are ignored. Therefore, you put that extra data
>>> inside a version(assert). But then those assertions fail to
>>> compile in release mode because the symbol lookup for that extra
>>> data fails. For this reason, assert statements should live inside
>>> version(assert) blocks by default.
>>
>> I've ran into an issue when implementing this feature back in February
>> (see the pull request):
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=9450
>> https://github.com/D-Programming-Language/dmd/pull/1614
>
> Oh, should have searched bugzilla before posting this.
>
> But would it be possible to implement it something like:
> During a release build, even though version(assert) blocks are compiled
> out of existence, the compiler would keep a separate list of symbols
> (and other info) of the things declared inside those version(assert)
> blocks. Then, when parsing assert expressions, if an undefined symbol is
> found, the compiler would check that separate list of symbols that it
> has been keeping, and if the symbol is found there and use of the symbol
> is syntactically correct, the compiler would just keep on going instead
> of spewing an "unidentified identifier" error.
>
> That way we'd make sure that things like:
>
> assert(this_identifier_doesnt_exist < 12);
>
> ...wouldn't compile.

It's always a bad idea to add special cases like this one for 
`version(assert)`. Anyway one will get into huge troubles trying to 
implement such stuff as I even can't imagine how it can be implemented 
consistently.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij


More information about the Digitalmars-d mailing list