View mode: basic / threaded / horizontal-split · Log in · Help
December 28, 2011
Re: string is rarely useful as a function argument
On Wednesday, 28 December 2011 at 19:00:53 UTC, Andrei 
Alexandrescu wrote:
> On 12/28/11 12:46 PM, Walter Bright wrote:
>> On 12/28/2011 10:35 AM, Peter Alexander wrote:
>>> On 28/12/11 6:15 PM, Walter Bright wrote:
>>>> If such a change is made, then people will use const string 
>>>> when they
>>>> mean immutable, and the values underneath are not guaranteed 
>>>> to be
>>>> consistent.
>>>
>>> Then people should learn what const and immutable mean!
>>>
>>> I don't think it's fair to dismiss my suggestion on the 
>>> grounds that
>>> people
>>> don't understand the language.
>>
>> People do what is convenient, and as endless experience shows, 
>> doing the
>> right thing should be easier than doing the wrong thing. If 
>> you present
>> people with a choice:
>>
>> #1: string s;
>> #2: immutable(char)[] s;
>>
>> sure as the sun rises, they will type the former, and it will 
>> be subtly
>> incorrect if string is const(char)[].
>>
>> Telling people they should know better and pick #2 instead is 
>> a strategy
>> that never works very well - not for programming, nor any 
>> other endeavor.
>
> Oh, one more thing - one good thing that could come out of this 
> thread is abolition (through however slow a deprecation path) 
> of s.length and s[i] for narrow strings. Requiring s.rep.length 
> instead of s.length and s.rep[i] instead of s[i] would improve 
> the quality of narrow strings tremendously. Also, s.rep[i] 
> should return ubyte/ushort, not char/wchar. Then, people would 
> access the decoding routines on the needed occasions, or would 
> consciously use the representation.
>
> Yum.
>
>
> Andrei

That's a good idea which I wonder about its implementation 
strategy. ATM string is simply an alias of a char array, are you 
suggesting string should be a wrapper struct instead (like the 
one previously suggested by Steven)?

I'm all for making string a properly encapsulated type.
December 28, 2011
Re: string is rarely useful as a function argument
Most common to me buffer reuse. I'll read a line of a file into a buffer, operate on it, then read the next line into the same buffer. If references to the buffer may escape, it's obviously unsafe to cast to immutable. 

Sent from my iPhone

On Dec 28, 2011, at 9:11 AM, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/28/2011 4:06 AM, Peter Alexander wrote:
>> I rarely *ever* need an immutable string. What I usually need is const(char)[].
>> I'd say 99%+ of the time I need only a const string.
> 
> I have a very different experience with strings. I can't even remember a case where I wanted to modify an existing string (this includes all my C and C++ usage of strings). It's always assemble a string at one place, and then refer to that string ever after (and never modify it).
> 
> What immutable strings make possible is treating strings as if they were value types. Nearly every language I know of treats them as immutable except for C and C++.
December 28, 2011
Re: string is rarely useful as a function argument
On 12/28/11 1:17 PM, Robert Jacques wrote:
> Would slicing, i.e. s[i..j] still be valid?

No, only s.rep[i .. j].

> If so, what would be the
> recommended way of finding i and j?

find, findSplit etc. from std.algorithm, std.utf functions etc.


Andrei
December 28, 2011
Re: string is rarely useful as a function argument
On 12/28/11 1:18 PM, foobar wrote:
> That's a good idea which I wonder about its implementation strategy.

Implementation would entail a change in the compiler.

Andrei
December 28, 2011
Re: string is rarely useful as a function argument
On 12/28/2011 08:18 PM, foobar wrote:
> On Wednesday, 28 December 2011 at 19:00:53 UTC, Andrei Alexandrescu wrote:
>> On 12/28/11 12:46 PM, Walter Bright wrote:
>>> On 12/28/2011 10:35 AM, Peter Alexander wrote:
>>>> On 28/12/11 6:15 PM, Walter Bright wrote:
>>>>> If such a change is made, then people will use const string when they
>>>>> mean immutable, and the values underneath are not guaranteed to be
>>>>> consistent.
>>>>
>>>> Then people should learn what const and immutable mean!
>>>>
>>>> I don't think it's fair to dismiss my suggestion on the grounds that
>>>> people
>>>> don't understand the language.
>>>
>>> People do what is convenient, and as endless experience shows, doing the
>>> right thing should be easier than doing the wrong thing. If you present
>>> people with a choice:
>>>
>>> #1: string s;
>>> #2: immutable(char)[] s;
>>>
>>> sure as the sun rises, they will type the former, and it will be subtly
>>> incorrect if string is const(char)[].
>>>
>>> Telling people they should know better and pick #2 instead is a strategy
>>> that never works very well - not for programming, nor any other
>>> endeavor.
>>
>> Oh, one more thing - one good thing that could come out of this thread
>> is abolition (through however slow a deprecation path) of s.length and
>> s[i] for narrow strings. Requiring s.rep.length instead of s.length
>> and s.rep[i] instead of s[i] would improve the quality of narrow
>> strings tremendously. Also, s.rep[i] should return ubyte/ushort, not
>> char/wchar. Then, people would access the decoding routines on the
>> needed occasions, or would consciously use the representation.
>>
>> Yum.
>>
>>
>> Andrei
>
> That's a good idea which I wonder about its implementation strategy. ATM
> string is simply an alias of a char array, are you suggesting string
> should be a wrapper struct instead (like the one previously suggested by
> Steven)?
>
> I'm all for making string a properly encapsulated type.

In what way would the proposed change improve encapsulation, and why 
would it even be desirable for such a basic data structure?
December 28, 2011
Re: string is rarely useful as a function argument
On 12/28/2011 08:30 PM, Andrei Alexandrescu wrote:
> On 12/28/11 1:18 PM, foobar wrote:
>> That's a good idea which I wonder about its implementation strategy.
>
> Implementation would entail a change in the compiler.
>
> Andrei

Special casing char[] and wchar[] in the language would be extremely 
ugly and inconsistent and would break nearly every D program. And for 
me, it would cripple Ds strings quite a lot. Why do you think it is 
worthwhile?
December 28, 2011
Re: string is rarely useful as a function argument
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei 
Alexandrescu wrote:
> On 12/28/11 1:18 PM, foobar wrote:
>> That's a good idea which I wonder about its implementation 
>> strategy.
>
> Implementation would entail a change in the compiler.
>
> Andrei

Why? D should be plenty powerful to implement this without 
modifying the compiler.  Sounds like you suggest that char[] will 
behave differently than other T[] which is a very poor idea IMO.
December 28, 2011
Re: string is rarely useful as a function argument
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei 
Alexandrescu wrote:
> Implementation would entail a change in the compiler.

I don't think I agree. Wouldn't something like this work?

===

struct string {
       immutable(char)[] rep;
       alias rep this;
       auto opAssign(immutable(char)[] rhs) {
               rep = rhs;
               return this;
       }

       this(immutable(char)[] rhs) {
               rep = rhs;
       }
       // disable these here so it isn't passed on to .rep
       @disable void opSlice(){  assert(0);  };
       @disable size_t length() {  assert(0);  };
}

===

I did some quick tests and the basics seemed ok:

/* paste impl from above */

import std.string : replace;

void main() {
       string a = "test"; // works

       a = a.replace("test", "mang"); // works
       // a = a[0..1]; // correctly fails to compile
       assert(0, a); // works
}
December 28, 2011
Re: string is rarely useful as a function argument
On 12/28/2011 08:29 PM, Andrei Alexandrescu wrote:
> On 12/28/11 1:17 PM, Robert Jacques wrote:
>> Would slicing, i.e. s[i..j] still be valid?
>
> No, only s.rep[i .. j].
>

That does not do the right thing. It would look more like 
cast(string)s.rep[i .. j].

>> If so, what would be the
>> recommended way of finding i and j?
>
> find, findSplit etc. from std.algorithm, std.utf functions etc.
>
>
> Andrei
December 28, 2011
Re: string is rarely useful as a function argument
On Wednesday, 28 December 2011 at 19:38:53 UTC, Timon Gehr wrote:
[snip]
>>
>> I'm all for making string a properly encapsulated type.
>
> In what way would the proposed change improve encapsulation, 
> and why would it even be desirable for such a basic data 
> structure?

I'm not sure what are you asking here. Are you asking what are 
the benefits of encapsulation? This topic was discussed to death 
more than once and I'd suggest searching the NG archives for the 
details. Also, If you hadn't already I'd suggest reading about 
Unicode and its levels of abstraction: code point, code units, 
graphemes, etc...
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home