Re: [boost] [unnullable_ptr] Proposal for a new library

From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-07-23 19:06:15

Andrey Tcherepanov wrote:

> bad_function_call will be thrown right now

I was unaware of that, but that's not much better IMO.
If I can use the type system to prevent exceptional erroneous situations
at runtime, that's better.

> Hmm... and what will happen if I call this when it is not initialized yet?

That is supposing function<sig> cannot be empty.
Using optional<function<sig> >, you get the same thing as the old behaviour.

optional is made so that you can make any type optional, so why not use
it when you need to achieve that need?

> So (if I understand you correctly), you want not function-pointer
> behaviour,
> but something more like reference - have to be initialized, cannot be null?

Well yeah, preventing an "empty" state means that you have to initialize
the thing, it cannot be null.
That's what the whole thread is about.

> It is usable, indeed, but instead of modifying existing Function
> (and fix all the user code), may be it is easier to create something new,
> something like FunctionRef library?...

Giving it another name or putting it in another namespace is of course
required to achieve compability.
The issue is that function is presented as being the right tool to use,
but better is possible.

Of course that is not function-specific. As I said, quite a few
constructs do not force the never-empty guarantee, and it would be
better they would (or alternative similar tools, making the current ones
deprecated) in my opinion, since that's a safer programming paradigm.

That reminds me of a discussion I read recently about iterators, which
have to be default constructible. I believe it is a bad idea to require
that, but Stepanov thought default-constructibility was an essential
propriety of regular types.

> BTW, shall it be not reassignable too?

Yes, there is no reason for that to change.
If you don't want it to be reassignable, simply make it const, I guess.

> If not, assignment should work like
> atomic op, and I am not sure if this is possible to implement for all
> user specified
> arguments simultaneously.

It should work like the current one but use techniques to make sure that
the object is not empty even if an exception is raised during its execution.