I just got it! (invariant/const)

[Janice Caron]

On 09/04/2008, Georg Wrede <georg at nospam.org> wrote:
> >    int f(invariant D d) { ... } invariant pure
> >
> > And that would mean that f takes as it's parameters the hidden
> > invariant parameter "this" and an invariant D d. It is pure, and
> > returns an int.
>
>  Which is precisely the same as the previous one?

No, again, that we my fault for misreading the question, and for which
I now feel very silly. The qualifiers are /not/ allowed following the
function body, and I apologise for giving that impression. However,
the following are all equivalent.

    int f(invariant D d) invariant pure { ... }
    int f(invariant D d) pure invariant { ... }
    pure int f(invariant D d) invariant { ... }
    invariant int f(invariant D d) pure { ... }
    pure invariant int f(invariant D d) { ... }
    invariant pure int f(invariant D d) { ... }

...unless of course pure implies invariant, which we would hope, in
which case you only have one of

    int f(D d) pure { ... }
    pure int f(D d) { ... }


>  Additionally, I seem to remember that stuff like
>
>  kljal alsje fss laskef(kajs aks) {
>
>   // potentially hundreds of lines here
>
>  } lksjd afaf
>
>  was frowned upon in D. Has this changed?

No. Apologies for confusion.


> > Well, they can be optimised away, at least.
>
>  They can be flatly removed!

That's what "optimised away" means. :-)


>   - Any pure function has to return a value.

To be /useful/ it has to return a value. To be /syntactically
correct/, probably not. For example:

    void doNothing(int x) pure
    {
    }

    int doSomething(int x) pure
    {
        doNothing(x);
        return x + 1;
    }

That looks OK to me. doNothing() will be optimised away completely,
but I think it needs to be /allowed/ because such a function could
conceivably arise as a result of template instantiation or string
mixin.


>   - In a pure function, ignoring the return value of a called function is an
> error.

I see no reason why that should be an error. Again, generic
programming might result in such code.


>  This is even stronger than (1) above, it is clearer,
>  and it's *right*.

Sure, but you don't need to outlaw code that does nothing. :-)