www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - An Invariant WTH?

reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
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.

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.

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

D2.0 just got closures, and I still get the feeling that I don't like 
const.  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.

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.

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?
Nov 04 2007
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chad J" <gamerChad _spamIsBad_gmail.com> wrote in message 
news:fglnam$eh8$1 digitalmars.com...
 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.

 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.

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

 D2.0 just got closures, and I still get the feeling that I don't like 
 const.  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.

 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.

 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?

You're not alone in feeling this way.
Nov 04 2007
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Nov 04 2007
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
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.
Nov 04 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Chad J wrote:
 <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>

To me, that suggests that the standard library is simply incomplete :P The problem with random access in a UTF-8 or UTF-16 string is that, AFAIK, there's no way to do it efficiently. You have to decode the *entire* string up to that index to find it. The way the dstring structure works is by switching to UTF-16 or UTF-32 as soon as you get multiunit codepoints showing up. I suppose in the end it really depends on what you're doing with your strings, and how frequently you do it.
 My point is that const seemed to be somewhat of an experimental feature
 in D.  If the experiment fails, we need to remove it!

Agreed. The trick will be finding an agreement for the conditions of failure :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...

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

True. That said, since I have a fairly big, complex project written in D 1.0, I'm really very happy with how the whole feature-freeze has turned out. It means I don't have to go fixing things that broke when I updated the compiler to squash a bug (which actually happened a few times.)
 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).

The funny thing is that an invariant array *works* like it's pass-by-value, basically by virtue of the fact that no one else can change it. As an example, you can't do this: int a = 1; int b = a; b += 5; assert( a == 6 ); // Nope But you *can* do this: char[] a = "foo"; char[] b = a; b[] = "bar"; assert( a == "bar" ); // Yup While invariant strings act like 'int' does: string a = "foo"; string b = a; //b[] = "bar"; // Doesn't work b = "bar"; assert( a == "bar" ); // Nope A practical use of this: in DOM, you can do this: char[] name = "tag-name"; new Element(name); The problem is that I don't know who "owns" the string that gets passed in. Currently, for the sake of efficiency, I don't dup strings passed in. However, this means that if anyone even accidentally changes the value pointed to by 'name', it can screw up the DOM tree. If I use 'string', on the other hand, I can pass them around willy-nilly as values. It's the same as passing around an int and not having to worry about the value of the int changing (unless you're using Java in which case the value of an int *can* apparently change.) You can't redefine, say, 0 to mean 8. Yes, they're still really references, but they work like values. So the ctor would probably become: this(char[] tagName) { this.tagName = tagName.idup; // Need an immutable copy } this(string tagName) { this.tagName = tagName; // No copy needed } Incidentally, this also protects me from having people (ie: myself when I'm not paying attention) go element.tagName[0] = 'x' or other silly crap like that.
 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.

It's more like a bug in Windows :P For instance, this cropped up in #d.tango a while ago: char[] tmp = "000"; Integer.format(tmp, cast(long) mode, Integer.Style.Octal); What no one realised was that this piece of code actually *redefines* the meaning of "000" every time it's run. Here's a more obvious example: char[] tmp1 = "000"; char[] tmp2 = "000"; tmp1[1] = '!'; writefln("tmp1: %s, tmp2: %s", tmp1, tmp2); This outputs "tmp1: 0!0, tmp2: 0!0". If you're unlucky, this will manifest itself in your code as *really weird* errors that are impossible to track down.
 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.

I don't know if there's much I can say to convince you. I think this is something that, until you *need* it, just seems like a pain-in-the-arse imposition. *I* used to think that languages with const were just trying to get in my way, until I started running into situations where it actually made my code simpler. -- Daniel
Nov 04 2007
parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Daniel Keep wrote:
 
 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).

The funny thing is that an invariant array *works* like it's pass-by-value, basically by virtue of the fact that no one else can change it. As an example, you can't do this: int a = 1; int b = a; b += 5; assert( a == 6 ); // Nope But you *can* do this: char[] a = "foo"; char[] b = a; b[] = "bar"; assert( a == "bar" ); // Yup While invariant strings act like 'int' does: string a = "foo"; string b = a; //b[] = "bar"; // Doesn't work b = "bar"; assert( a == "bar" ); // Nope A practical use of this: in DOM, you can do this: char[] name = "tag-name"; new Element(name); The problem is that I don't know who "owns" the string that gets passed in. Currently, for the sake of efficiency, I don't dup strings passed in. However, this means that if anyone even accidentally changes the value pointed to by 'name', it can screw up the DOM tree. If I use 'string', on the other hand, I can pass them around willy-nilly as values. It's the same as passing around an int and not having to worry about the value of the int changing (unless you're using Java in which case the value of an int *can* apparently change.) You can't redefine, say, 0 to mean 8. Yes, they're still really references, but they work like values. So the ctor would probably become: this(char[] tagName) { this.tagName = tagName.idup; // Need an immutable copy } this(string tagName) { this.tagName = tagName; // No copy needed } Incidentally, this also protects me from having people (ie: myself when I'm not paying attention) go element.tagName[0] = 'x' or other silly crap like that.

I like where that's going. Thanks for that. I'm still not convinced that it's worth the increased complexity in the language, but that doesn't affect me as a programmer so much, which means I can deal with it. Now I at least have a design pattern or two that leverages this constness thing.
 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?

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!

system. It tells me that the way string literals are handled is broken and platform dependent.

It's more like a bug in Windows :P For instance, this cropped up in #d.tango a while ago: char[] tmp = "000"; Integer.format(tmp, cast(long) mode, Integer.Style.Octal); What no one realised was that this piece of code actually *redefines* the meaning of "000" every time it's run. Here's a more obvious example: char[] tmp1 = "000"; char[] tmp2 = "000"; tmp1[1] = '!'; writefln("tmp1: %s, tmp2: %s", tmp1, tmp2); This outputs "tmp1: 0!0, tmp2: 0!0". If you're unlucky, this will manifest itself in your code as *really weird* errors that are impossible to track down.

Yuck. This is all wrong. Windows is wrong, and D is too. I thought that part of the design philosophy in D is that program correctness comes first, while at the same time giving the programmer the tools needed to optimize as far as possible. The way literals are handled in D1.0 violates that. In this case the programmer assigns to a variable from a literal. The following things may happen: +----------------------------------+ | action taken by the language | |----------------------------------| | dup on assign | ref the literal | --------------+---------------+------------------+ string only | efficiency | everything is | read | loss* | fine | --------------+---------------+------------------+ string gets | everything is | segfault or hard | modified | fine | to find bugs | --------------+---------------+------------------+ * This may very well be a heap allocation if the compiler doesn't know what the programmer does with the duplicate. Escape analysis could potentially reduce some cases to a stack allocation with a mem copy. "Scope" allocated variables and manual stack allocation would also provide means for the programmer to optimize away the inefficiency. Use of static variables can also turn it into a one time startup cost. I think that the "dup on assign" path would be superior. I get this feeling that the loss in performance would have been moot compared to the obscure bugs caused. This is especially the case if the programmers who care about speed apply the trivial optimizations like static and scope variables. Constness does seem to provide a better answer to this, though it'd be nice if there was an implicit dup for literals being assigned to non-invariant/non-const types, or at least a better error message.
 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

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.

I don't know if there's much I can say to convince you. I think this is something that, until you *need* it, just seems like a pain-in-the-arse imposition. *I* used to think that languages with const were just trying to get in my way, until I started running into situations where it actually made my code simpler. -- Daniel

Well, thanks for trying at least.
Nov 05 2007
prev sibling parent reply "Kris" <foo bar.com> writes:
Chad: sounds like you need Tango for your text processing needs ...


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

Nov 05 2007
parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Kris wrote:
 Chad: sounds like you need Tango for your text processing needs ...
 

Yeah I've been itching to try Tango on a project where I run into these things. I get the feeling it uses templates to sidestep the whole char[]/wchar[]/dchar[] crap. Then I'd be able to just use dchar[] all the time and thus get my random indexing. Computers like working with 32 bit wide things anyways. So yeah, I've been convinced of this for a year, but that's also been the year when I haven't done much coding.
Nov 05 2007