[lmi] Dynamic in-class initialization immoral? [Was: [lmi-commits] master 9b3d0f1: Write explicitly-defaulted [cd]tors inline, in class defn]

[Greg Chicares]

On 2017-03-06 00:04, Greg Chicares wrote:
> [///] However, I still have twenty-one files to go,
> which are the thorniest

Is the following patch immoral?

---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
diff --git a/global_settings.hpp b/global_settings.hpp
index ecc8771..20c5465 100644
--- a/global_settings.hpp
+++ b/global_settings.hpp
@@ -27,6 +27,7 @@
 #include "calendar_date.hpp"
 #include "so_attributes.hpp"
 
+#include <boost/filesystem/operations.hpp> // fs::system_complete()
 #include <boost/filesystem/path.hpp>
 
 #include <string>
@@ -96,7 +97,8 @@ class LMI_SO global_settings final
     std::string pyx_;
     bool custom_io_0_;
     bool regression_testing_;
-    fs::path data_directory_;
+//  fs::path data_directory_ = (fs::system_complete("."));
+    fs::path data_directory_ {fs::system_complete(".")};
     calendar_date prospicience_date_;
 };
 
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

[Either syntax compiles successfully:
 - with '=', as in the commented-out line; or
 - with {}
]

This gives me pause because
  fs::system_complete(".")
need not always return the same path--it depends on the lunar phase.
We're using boost-1.33.1 and the following quote is from a version
prior, but I know 1.33.1 says substantially the same thing:

http://www.boost.org/doc/libs/1_32_0/libs/filesystem/doc/operations.htm#system_complete
| For Widows, system_complete( ph ) has the same semantics as
| complete( ph, current_path() ) if ph.is_complete() || !ph.has_root_name()
| or ph and base have the same root_name(). Otherwise it acts like
| complete( ph, kinky ), where kinky is the current directory for the
| ph.root_name() drive. This will be the current directory of that drive
| the last time it was set, and thus may well be residue left over from
| some prior program run by the command processor! Although these semantics
| are often useful, they are also very error-prone, and certainly deserve
| to be called "kinky".

But my concern isn't the bizarre way in which this is dynamic: it's that
it's dynamic at all. Every other in-class initializer we've written so far
in lmi has a value that's always the same. Now, the patch above compiles,
so it's legal, but is it moral?

If it isn't moral, then that doesn't mean we can't initialize this member
in the class--we'd simply initialize it to something empty or invalid,
and then reset it in the ctor-initializer. Then we'd have to conclude that
not every ctor-initializer can be replaced with an in-class initializer
that does the same thing; that's fine with me as long as we agree.

OTOH, can it really be moral? And even if it is, doesn't it still smell
risky? I would guess that a reasonable C++ implementation might ascertain
and store its value as of some particular moment (e.g., upon the first
call to any ctor), and then reuse that value without repeating the function
call, but that could easily be the wrong thing to do here. (I can't find
specific guidance on that point in the standard.)