An Invariant WTH?

[Chad J]

Daniel Keep wrote:
> 
> 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.
> 

Hmmm.  I thought the assignment would cause copying, thus it didn't seem 
necessary to have const in this case.

>> 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.
> 

<ramble thats somewhat OT>
I frequently find myself in this situation where I want to iterate over 
a string, and at the same time be able to index the string an arbitrary 
number of elements ahead or behind the current one.  Either that, or I 
want to iterate through 2 strings in parallel, using the same index to 
do operations on both.  I forget why these things happen, but they do, 
and foreach is just not adequate for decoding the UTF stuff.  By the 
very act of iteration, it does define a way to index UTF8 strings, and I 
wish that definition could be applied to random access.  My other 
alternative is to use dchars, which just doesn't work that well with 
phobos, considering everything in phobos uses char[].  I haven't tried 
writing a dchar[] using program with tango yet.

I wish I could be more thorough about this though.  I believe it 
deserves more thought on my part.  It's also starting to be less 
relevant to the whole const discussion, so I'd rather just leave this at 
"string the keyword can probably be better allocated".
</ramble thats somewhat OT>

>> 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
> 

I remember this.  Const was going to be great.  It doesn't seem to be 
delivering.

Do we have any examples of programs experiencing dramatic bug reduction 
after switching to D2.0?  Are there benchmarks proving the performance 
increase?

Well, if the current const system really is considered obsolete, then 
this stuff can probably wait.

My point is that const seemed to be somewhat of an experimental feature 
in D.  If the experiment fails, we need to remove it!

>> 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...
> 

The problem is that D1.0 gets the shaft for new features that it would 
have otherwise benefited from.

>> 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.
> 

The pass-by-ref vs. pass-by-val seems juicy, but I don't think I 
understand entirely.  How does constness solve this?  Aren't strings 
ALWAYS referenced to, or are you referring to the reference itself being 
a value or something referred to?  A simple code snippet demonstrating 
this would be great (you can refer me to this if it's been done).

>> 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!
> 

Maybe I am stubborn, but that doesn't tell me that D needs a const 
system.  It tells me that the way string literals are handled is broken 
and platform dependent.

> 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

While I am certainly venting a bit about this, I do want to resolve this 
somehow.  By "this" I don't mean constness, I mean my personal issues 
with constness.  Since const doesn't seem to be going away but rather 
just changing a bit, I am left with one other option: to make me, an 
angry const-hater, into someone who is not an angry const-hater.