It seems common practice to put a hint to not yet implemented code in a comment starting with "TODO" or similar wording.

Therefore I believe that compiler assistance for this behaviour should be available.

The language allows for a `todo' statement, which may be a keyword- only  statement or similar to a line comment starting with keyword `todo'.

The compiler allows for an option "-beta", which has the semantics of issuing a "still alpha stage" error iff there are `todo' statements in the code.

The current semantics of the compiler option "-release" then sticks
with a new
"-airy" or
"-dmc" ( short for "devil may care")
option.

The "-release" option becomes a shortcut for
"-beta -airy -O -inline".

The current semantics of "-O" and "-inline" is changed so that an
XORing with the semantics provided by "-release" takes place. I.e.:
- if "-release" is present on the command line
-- any additional "-O" disables optimization, and
-- any additional "-inline" disables inlining
- if "-release" is _not_ present on the command line, then the
command line options "-O" and "-inline" keep their current semantics.

-manfred

Manfred Nowak wrote:
> It seems common practice to put a hint to not yet implemented code in a comment starting with "TODO" or similar wording.
> 
> Therefore I believe that compiler assistance for this behaviour should be available.

> 
> The language allows for a `todo' statement, which may be a keyword-
> only  statement or similar to a line comment starting with keyword `todo'.

I don't think anything that changes the output of code should be im-beded in comments, it would be hard to debug.

> 
> The compiler allows for an option "-beta", which has the semantics of issuing a "still alpha stage" error iff there are `todo' statements in the code.

In C++ I've done this before using the macro language.  Instead of passing in =beta you'd pass in a BETA pre-define. Actually it was more complicated then that.  We had several levels of todo Alpha_TODO(), Beta_TODO(), Milestone_TODO(), Sprint_TODO() ...

> 
> The current semantics of the compiler option "-release" then sticks with a new "-airy" or
> "-dmc" ( short for "devil may care")
> option.


While having some todo support in the code would be nice, I'm not sure how it would be supported.  And I don't think its useful enough to earn its own keyword.

In C++ I used to put in message pragmas.  It would be nice if you could some how generate a message like "There are 91 todos left in the code".  I imagine that something like that could be done in a way that is useful for all sorts of thing other then just todos.  If you had compile time globals, it would be possible to write the code yourself.  It is possible in C++ macros, but it is as nasty as hell.

> 
> The "-release" option becomes a shortcut for
> "-beta -airy -O -inline".

A release option would be nice.

> 
> The current semantics of "-O" and "-inline" is changed so that an XORing with the semantics provided by "-release" takes place. I.e.:
> - if "-release" is present on the command line
> -- any additional "-O" disables optimization, and
> -- any additional "-inline" disables inlining
> - if "-release" is _not_ present on the command line, then the command line options "-O" and "-inline" keep their current semantics.

This is very confusing and bug prone.  It also means more work for IDE writers.  I'd recommend using a different symbol to turn off things, ie "--O" "--inline".
> 
> -manfred

Manfred Nowak wrote:
> It seems common practice to put a hint to not yet implemented code in a comment starting with "TODO" or similar wording.
> 
> Therefore I believe that compiler assistance for this behaviour should be available.
> 
> The language allows for a `todo' statement, which may be a keyword-
> only  statement or similar to a line comment starting with keyword `todo'.

Nice idea. How about

   pragma(todo, "Message");



   -- Reiner