preparing for const, final, and invariant

[Brad Roberts]

Not that this debate has any value, since const, et al are currently 
being implemented and that's not remotely likely to change, but here's 
my opinion, for what it's worth:

For any non-trivial application, const (and it's stronger brother 
invariant) is a must to allow me and the people I work with to both 
specify the behavior of routines in their signature, and to actually 
provide enforcement.  I can't consider a language without the ability to 
make these sorts of guarantees without stupid work around like copying 
data left and right a usable language.  It's an interesting toy, but it 
can't graduate to anything besides toy apps.  I recognize that non-toy 
apps have been written with D, and that's great.  So, for me, const is 
an 'every app' layer feature, or at least any library / application of 
significant size.  There's no way in hell that 'const' can be called a 
nerd feature.

Reflection, while a very very powerful feature, is something that's 
useful in a subset of applications.  Additionally, it's not like 
reflection has been totally ignored.  The features of it have _also_ 
been increasing over time.  D might not match Java yet, but few features 
of this weight are black and white.  Between CTFE, Mixins, and the 
compile time reflection that's already available, I suspect it's 
possible to write a reflection library that covers a high percentage of 
java's functionality.  I highly encourage anyone who is in serious need 
of runtime reflection take a stab at it and report back a prioritized 
list of what's missing.

Later,
Brad

BLS wrote:
> I agree. (and I am afraid that reflection will take along long time) 
> Bjoern
> 
> bobef Wrote:
> 
>> Without any disrespect to the great work you are doing, let me put
>> it in another way: In order to make a good, *usable* application,
>> is this "const final scope" thing more important or having a good
>> GUI library? There are not many console applications these days,
>> you know. And they are not very *usable*. And, as we all know,
>> choosing a GUI for D is not like choosing a GUI for C++. So why
>> instead of adding nerd stuff to the language, make it sooooo much
>> more *usable*, by fixing the reflection stuff that Tioport needs to
>> produce libraries which are not 10mb or 20mb? Or... it kind of
>> sucks when half of my code won't compile, or compiles in specific
>> order only, because of some forward reference errors. I don't even
>> know what forward reference is, but I know that using (simple)
>> consts and aliases is something perfectly legal. I don't know if
>> this second example is more usable than the final cosnt thing, just
>> because I can't think of any use of it, but this is because I
>> rarely use fancy stuff that breaks my code in the next version of
>> DMD... But I am making this example to show that D (or DMD) still
>> have so many things to fix the way it is now, we don't need some
>> new fancy stuff before the old things work....
>>