On 2014-02-03 16:03, Roland Bock wrote: In most usecases I encountered so far, it is totally OK to interpret NULL values like default values, e.g. NULL strings and empty strings, or NULL foreign keys or 0LL. For those usecases it would be quite annoying to have to check if there really is a value, or always use get_optional_value_or...
Hi Roland, while I can very well imagine that these "use-cases" exist, I would not like the library to make this the default. I think using boost::optional is the canonical solution that is also impossible to misinterpret. Treating non-existent values the same as default-initialized values seems error-prone if not wrong in general. The library should not prevent me from treating string "" differently from NULL, which currently it does. On the other hand, if the library did return optionals, implementing the behaviour you describe on top of it is trivial: boost::optional<T> t; t.get_value_or( T() ); If it helps my argument, both Scala Anorm and Scala Slick represent nullable columns as optional types: http://www.playframework.com/documentation/2.0/ScalaAnorm http://slick.typesafe.com/doc/2.0.0/schemas.html Regards Sebastian PS: I hope to look at your library in more detail in the coming weeks and I am really looking forward to that. Great work so far. -- Dr. Sebastian Theophil | stheophil@think-cell.com Senior Software Engineer think-cell Sales GmbH & Co. KG | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRA 44531 | European Union VAT Id DE815233792 General partner: think-cell Operations GmbH | Amtsgericht Berlin-Charlottenburg HRB 129917 Directors: Dr. Markus Hannebauer, Dr. Arno Sch?dl