Le 26/05/2017 à 18:16, Niall Douglas via Boost a écrit :
On 26/05/2017 15:23, Peter Dimov via Boost wrote:
Niall Douglas wrote:
But after I built up some experience, now I tend to write this instead:
result<Foo> something() { result<Foo> ret(Foo()); Foo &foo = ret.value(); ... build foo ... return ret; } This takes us back to "what if due to a logic error the code that should build `foo` doesn't?"
And since you've constructed `ret` to non-empty, the point of empty is, again, lost. But if I am writing my implementation that way, it is because there is no purpose here to my function returning empty. Else I would implement it differently. If the function can not return empty it should use another type, isn't it? Well I can admit that you must follow a specific protocol and return a result<T> even if in this specific case it cannot be empty.
I appreciate that the above is me speaking vaguely from experience and without concrete evidence. But I think most programmers, once they are using these objects for a while, will start to naturally write code which never *could* return an empty object if returning an empty object makes no sense for that function. Equally, if some function could return an empty object, the programmer will structure their code appropriately. If we don't have cases where we can return empty, I don't see why we want to support it. Vicenet