An Invariant WTH?

[Daniel Keep]

Chad J wrote:
> import std.stdio;
> 
> void main()
> {
>   char[] hello = "Hello world!";
>   writefln( hello );
> }
> 
> ----------------------
> 
> main.d(5): Error: cannot implicitly convert expression ("Hello world!")
> of type invariant char[12u] to char[]
> 
> ----------------------
> 
> I know that `string hello = "Hello World!";` would cause the desired
> results, but this makes me have to learn all about constness and
> invariance just to make very trivial programs.  More learning curve =
> BAD.  Also, if I wanted to do an inplace toLower or somesuch on the
> "Hello World!" string, then things get more complicated than in 1.0.

Trying to do an in-place toLower on "Hello World!" is a *BUG*.  The
contents of string literals are stored in the data segment, which is
supposed to be read-only (apparently not on Windows, though.)  If you
took that code and tried to run it on, AFAIK, any non-Windows OS, you'd
get segmentation faults.  Then you'd complain that D didn't catch the
error; and if not you, then someone else would, because that's what
people have done before!  This is one of the major reasons why people
want a const system.

> It also disturbs me that "string" is just one of "wstring" and
> "dstring", and not a more useful generic string type like the dstring
> that Chris Miller wrote.

I'm not entirely convinced that would be better (although I'm not
entirely convinced that it wouldn't.)  Once we have implicit
conversions, however, you can probably get away with just using a string
struct/class in your own code, and automatically convert to the required
array type.

Personally, I've never had an issue with using straight arrays.

> Not to mention the massive drain on D community's and Walter's resources
> that this has caused.

This is true.  const is a huge, nasty problem.  But keep in mind that
before this all started, there were fairly regular posts to the
newsgroup asking when D was going to get a const system.  A number of
people came in here and said they wouldn't even consider using D until
it had a const system to back them up.

It's not like Walter just got up one day and decided "I think I'll
design a new const system!"

Well, OK.  Maybe he did.  But it's not like we weren't bugging him to do
so :P

> D2.0 just got closures, and I still get the feeling that I don't like
> const.

<JohnCleese> I'm sorry, but... this is irrelevent.
<MichaelPalin> Leaping from tree to tree down the mighty rivers of
British Columbia...

> So I'm wondering if it is irrational to have this feeling that
> I'm getting some sort of ugly const thing shoved down my throat.

I'll be clear: I want const.  I seem to be one of the few people who
actually grokked and liked the originally proposed const system.  That
said, if you don't like something, it's normal to, well... not like it.

> Bitching and moaning aside, there's got to be a reason we are doing this
> const thing.  Something good.  Something besides "C/C++ needed it to be
> less buggy" - C and C++ tend to need a lot of bug fighting measures in
> places that D conveniently doesn't really need much help in.  Also,
> something besides "it'll make your program 1% faster".  I was not
> convinced by those.

Again, maybe it's just me, but when I write code, I'm constantly
thinking to myself "I really wish I had const here."  One of the big
things it buys you is the ability to express intent.  For example, I'm
(on and off) writing a full DOM implementation for D.  One of the issues
is: what to do with string data.

My two options are: dup every string that comes in, or just reference
it.  The problem with the first is that it's much less efficient if I
don't need to do those dups.  The problem with the second is that it
makes keeping my memory profile down much harder: I can never actually
tell whether I "own" a piece of memory or not.

If I had const, I could make two versions of the setter functions, and
only dup if it's actually necessary.  This would be a big gain for me
not because of the efficiency gain, but because I no longer have to go
around worrying about whether a particular method is pass-by-value or
pass-by-reference.  I no longer have to go and look up "now, am I
allowed to change this array, or will that cause Bad Things to happen?"
 I can actually get the compiler to check for me.

> It's all cost-benefit.  I'm seeing a lot of cost with little or dubious
> benefit.  So why should I be convinced that this is the right thing to
> do?  Why should I be willing to write D2.0 code?

If you're happy with D 1.0, then stick with that (no, this isn't a "if u
dont leik it, get lost!" comment.)  If you want to use the other
features of D 2.0, start writing in it and point out where the const
system fails.  The example you gave at the start of this post is, in
fact, a prime case for *having* a const system, since you didn't even
realise you were making a mistake!

Me?  I'm going to wait until Walter unveils the changes to the const
system.  Arguing about something that's already been declared obsolete
is somewhat pointless :P

	-- Daniel