1. 18

So there is a bit of a debate raging over in the D Language forums on a assert semantic change proposal.

But that isn’t what I want to discuss here.

I have just realized this makes a perfect job interview question….

“In the last program you wrote, would you be comfortable if the optimizer relied on the assert expressions you wrote being true, even if they were compiled out of the code?”

Why? Because your answers are going to tell me so much about your coding style and experience.

The meaning and use of assert’s is subtly ill defined, so there actually is no One True Right answer.

Oh for sure, if you follow that thread you will see my own behaviour falls sharply on one side…. but that doesn’t mean I’m Right… merely I that I have a particular style of programming.

I really like this question as there is no correct answer, and the reasons you state for your answer tells me about you, and your experience, nothing else.


  2. 7

    Given the right interviewer and the right organization, if I was asked this question at Amazon, Facebook or Google most of my effort would go into reading the interviewer to figure out their opinion.

    Asserts could aid in static analysis and unit tests could guide the optimizer.

    Why not just add real properties to the language so it can run Quickcheck?

    1. 2

      into reading the interviewer to figure out their opinion.

      And as an interviewer I would be probing you to justify your opinion, whatever it is.

      If you’re sitting there trying to read my opinions I’d see a wet fish who lacks his own. I’d rather work with someone who knows what he is doing, even if it is different to me… than one who doesn’t know what or why he is doing.

      1. 7

        Which I already pegged as defiant, steadfast and prone for debate, I would have passed with flying colors. ;)

        I have been through so many bad interviews, as both participants, that I find the whole thing irksome. How about as a starter for an interesting discussion instead of an interview question? Or maybe interview in the general sense, not a job. Job interviews are too one sided. Esp when the candidate actually wants to get hired.


    2. 5

      One justification: assertions ought to demarcate assumptions the code requires in order to function, present or otherwise. So long as that relationship holds then this is extra information about the meaning of the code that the compiler ought to be able to use to better optimize things and that information is valid whether or not asserts themselves are compiled in.

      1. 5

        Here’s my answer after brief consideration: Preposterous! Any assertions I put in my code are for my own defense, against authoring poor software. Assertions aren’t to be twisted into something that can be used against me. In fact, if the compiler wants to be smart, it ought to turn my assertions into compile-time guarantees!

        It’s a great question though, because I know my own answer is wrong for at least one reason and probably more.

        1. 4

          If there’s no correct answer, does that mean there’s no wrong answer? I mean, what if the answer was “I don’t use asserts so it wouldn’t matter”?

          False negatives (rejecting a candidate who would have been acceptable) are less important than false positives (accepting a candidate who’s no good). So I don’t see how this makes a good interview question.

          1. 1

            Let A be the set of correct answers, and C the set of answers both right and wrong, |A| ≠ 1 does not imply |C \ A| = Ø.

            Like OP said, there is no one right answer. Answers are a yes or no, backed up by arguments for or against the practice.

            1. 1

              “I don’t use asserts so it wouldn’t matter”?

              So long as you had good reasons for not using them, and had strategies that compensated for not using them, and could explain how you’d work in a code base that did have them.

            2. 3

              For those that don’t understand the question, this is a good starting point (not D-specific):


              1. 3

                This reminds me of an earlier post of a John Regehr blog post that touches on this topic.

                To me it makes sense to have distinct mechanisms for expressing assertions and assumptions, and, as I commented on that post, Julia actually has a number of handy macros you can use to tell the compiler to assume things (e.g. all array accesses in this expression are inbounds, this loop is safe to vectorize).

                1. 3

                  Asserts are intended to guard against programmer errors and should have no side effects; certainly nothing that changes program behavior. Likewise, the optimizer is not supposed to change the externally visible behavior of the program. So long as the externally visible behavior remains unchanged, I don’t see a problem with an optimizer making use of the implications of an assertion.

                  To the flip that around, if an assertion does not hold it indicates that there’s an error in the program logic. One of the other classic tenets about optimizers is that it’s no sin if an optimizer breaks an already broken program (at least where undefined behavior is concerned).

                  A third take: compiling out assertions is already a form of optimization, anyway.

                  So yes, it’s fair game in my opinion. That said, for C or C++ at least, most production compilers have pragmas to give hints to the optimizer, e.g. ivdep. Given the precedent, that seems the better mechanism for this sort of thing. A #pragma assert(...) that promised the optimizer conditions that it might not spot on it’s own could be kind of neat.

                  1. 2

                    Yes. I use asserts as a tool for doing Design by Contract. We leave asserts compiled in and running in production. If the optimizer can use them for something other than finding bugs, go for it!

                    If the optimizer can output a fast path assuming domain of the input based in the asserts, fine by me!

                    1. 1

                      it’s a bit of an odd question i think.

                      the standard definition of assertions is pretty different from the functionality you’re offering.

                      1. 1

                        So, here’s how I reason about it.

                        Asserts are there to catch programmer errors. Mostly when I use asserts it is to guarantee pre- and post- conditions on the data entering/leaving a function, or to verify internal state (say, in a linked-list implementation or ringbuffer). When I compile in release, I disable the assertion code, and pray my test suite picks up runtime issues.

                        So, in essence, the asserts are there to guarantee that a function abides by its declared contract. In theory, that in turn means that asserts are a clumsy (but useful!) mechanism for guaranteeing type information (this type of input is what makes it in, this type is what makes it out, side effects are of this type, etc.).

                        So, theoretically, yes, I’d be comfortable letting the optimizer use that information.

                        Practically, unless I’m careful, I may leave off an assert or two and hence give it too much wiggle room–and that in turn makes me nervous.

                        1. -1

                          I don’t use assertions. I work in languages where I can state theorems and provide evidence to them. The compiler can do whatever it likes with that (a lot of the time it’s just erasing the evidence).

                          I also work in languages where functions must be total. An assert makes no sense at all there.