I was thinking the same when discussing an earlier proposal with
Johanna. The "configopt" idea came out of that with the observation
that "const &redef" isn't quite fitting here (and, as you say, it's
already blurred anyways). At that time, however, the thinking was
still to have a 2nd namespace, and writing 'configopt X: string
&config="a.b.c"' seemed a bit too much. But if we just go with a more
generic display name via Broxygen, then I'm back to liking it --
except maybe for the name, how about "option" instead of "configopt"?
So we'd arrive at something like this (similar to what has been said
already):
I like that - I honestly did not really like configopt from the beginning,
the only reason for choosing it is that "config" conflicts with the
input/logging framework.
I am not completely sure we should deprecate const &redefs - there might
actually be a need for constants that can really only be changed on
startup. I like the idea of Jon to also remove the current ways to
manipulate &costs at runtime though
## The username for our new feature.
##
## Display: User Name
option user_name: string;
}
I really like that syntax! I think Jon is right regarding the semantics
that the "const" keyword implies (I missed that in my first mail). Using
"option" instead looks like a nice and clean solution.
Following the discussion, I think Vlad managed to explain what I had on
my mind as well: The language should not be polluted with elements just
to force developers to add documentation. Especially because there is
already a convenient mechanism for documentation. Adding "Display:" as a
broxygen keyword fades in nicely while separate concerns (i.e. code and
documentation) keep separate.
