I just got it! (invariant/const)

Bill Baxter dnewsgroup at billbaxter.com
Wed Apr 9 20:47:04 PDT 2008


Lionello Lunesu wrote:
> 
> "Jason House" <jason.james.house at gmail.com> wrote in message 
> news:ftislk$3m0$1 at digitalmars.com...
>> Janice Caron Wrote:
>>
>>> On 09/04/2008, Georg Wrede <georg at nospam.org> wrote:
>>> >  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. :-)
>>
>> D already outlaws having code that isn't run.  I would prefer for code 
>> that does nothing to be considered an error.  Of course, with most 
>> functions being impure, that's tough to enforce.  With pure functions, 
>> it should be easy.
> 
> Why? If pure-ness (uh, purity?) can be checked, it can also be deducted 
> (*), so the compiler could optimize/complain in either case.

I was thinking along the same lines last week or so.  A lot of things
about a method signature can be deduced from what's inside.  Including
types of the arguments in many cases.  Languages like ML take this to
the extreme.  But the point of putting the info explicitly in the
signature is so that
A) the compiler doesn't need to see the implementation right away to
tell what's inside (separate compilation).
B) Joe Programmer doesn't have to see the implementation to know if he
can call it or not (documentation).
C) Fred Programmer can declare his intent to Joe that the method work in
such a way, and the compiler can tell Fred if what he though was true is
not (verification).

CTFE-ness is automatically deduced by the compiler, but using CTFE
always requires access to the source of the method so A) is not an
issue.  Still it might be nice to have a "ctfe" tag for purpose B).

So I think deduction of such stuff is not really viable overall.
Perhaps it could be allowed for templates though?  The source is
required to be available for those anyway.

--bb



More information about the Digitalmars-d mailing list