An Invariant WTH?

[Kris]

Chad: sounds like you need Tango for your text processing needs ...


"Chad J" <gamerChad at _spamIsBad_gmail.com> wrote in message 
news:fgm0v1$qug$1 at digitalmars.com...
> 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.