https://issues.dlang.org/show_bug.cgi?id=23678

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |razvan.nitu1305@gmail.com
         Resolution|---                         |INVALID

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
The contract is dropped (i.e. it does not appear in the executable file), but that does not mean it is not analyzed. You are getting an error because your code does not pass semantic analysis.

We cannot implement this because then you might have semantically incorrect code in your contract and the compiler needs to report it regardless of the fact that it does not get generated in the object code.

--

https://issues.dlang.org/show_bug.cgi?id=23678

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl

--- Comment #2 from Dennis <dkorpel@live.nl> ---
> We cannot implement this because then you might have semantically incorrect code in your contract and the compiler needs to report it regardless of the fact that it does not get generated in the object code

It's not set in stone that the compiler has to report semantic errors in contracts. Note that currently, you can have semantically incorrect code in unittest blocks if you don't compile with -unittest. (In fact, it doesn't even have to parse correctly, the parser just skips to the next bracket)

However, contracts can affect attribute inference: a `@system` contract will make calling that function `@system`. Changing function attributes based on -checkaction switches can result in linker errors with separate compilation.

--