Jump to page: 1 216  
Page
Thread overview
string is rarely useful as a function argument
Dec 28, 2011
Peter Alexander
Dec 28, 2011
bearophile
Dec 28, 2011
Peter Alexander
Dec 28, 2011
bearophile
Dec 28, 2011
Peter Alexander
Dec 28, 2011
Walter Bright
Dec 28, 2011
Peter Alexander
Dec 28, 2011
Timon Gehr
Dec 28, 2011
Peter Alexander
Dec 28, 2011
Walter Bright
Dec 28, 2011
Peter Alexander
Dec 28, 2011
Walter Bright
Dec 28, 2011
Walter Bright
Dec 28, 2011
Robert Jacques
Dec 28, 2011
Timon Gehr
Dec 28, 2011
foobar
Dec 28, 2011
Timon Gehr
Dec 28, 2011
foobar
Dec 28, 2011
foobar
Dec 29, 2011
Adam D. Ruppe
Dec 29, 2011
Walter Bright
Dec 29, 2011
Adam D. Ruppe
Dec 29, 2011
Adam D. Ruppe
Dec 29, 2011
Jakob Ovrum
Dec 29, 2011
Jonathan M Davis
Dec 29, 2011
deadalnix
Dec 29, 2011
Walter Bright
Dec 29, 2011
Walter Bright
Dec 29, 2011
Timon Gehr
Dec 29, 2011
Derek
Dec 29, 2011
Sean Kelly
Dec 29, 2011
Jonathan M Davis
Dec 28, 2011
Adam D. Ruppe
Dec 28, 2011
foobar
Dec 28, 2011
Adam D. Ruppe
Dec 28, 2011
Timon Gehr
Dec 28, 2011
foobar
Dec 28, 2011
Timon Gehr
Dec 28, 2011
Timon Gehr
Dec 28, 2011
Jonathan M Davis
Dec 28, 2011
Timon Gehr
Dec 28, 2011
foobar
Dec 28, 2011
Timon Gehr
Dec 29, 2011
foobar
Dec 29, 2011
Timon Gehr
Dec 28, 2011
bearophile
Dec 29, 2011
Vladimir Panteleev
Dec 29, 2011
Gor Gyolchanyan
Dec 29, 2011
Walter Bright
Dec 29, 2011
Gor Gyolchanyan
Dec 29, 2011
Gor Gyolchanyan
Dec 29, 2011
Don
Dec 30, 2011
Regan Heath
Dec 30, 2011
Joshua Reusch
Dec 30, 2011
Timon Gehr
Dec 30, 2011
Jakob Ovrum
Dec 30, 2011
deadalnix
Dec 30, 2011
Timon Gehr
Dec 31, 2011
Chad J
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Chad J
Jan 01, 2012
deadalnix
Jan 01, 2012
Timon Gehr
Jan 04, 2012
deadalnix
Jan 04, 2012
Timon Gehr
Jan 04, 2012
Timon Gehr
Dec 30, 2011
Walter Bright
Dec 30, 2011
Timon Gehr
Dec 30, 2011
Timon Gehr
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Don
Dec 31, 2011
Timon Gehr
Jan 01, 2012
Don
Jan 01, 2012
Timon Gehr
Dec 31, 2011
Sean Kelly
Dec 30, 2011
Walter Bright
Dec 31, 2011
Michel Fortin
Dec 31, 2011
Jonathan M Davis
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Walter Bright
Dec 31, 2011
Brad Anderson
Dec 31, 2011
Walter Bright
Dec 31, 2011
kenji hara
Dec 31, 2011
Michel Fortin
Dec 31, 2011
Vladimir Panteleev
Dec 31, 2011
Michel Fortin
Dec 31, 2011
Michel Fortin
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Sean Kelly
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Michel Fortin
Jan 01, 2012
Sean Kelly
Dec 31, 2011
bearophile
Dec 31, 2011
Piotr Szturmaj
Dec 31, 2011
Chad J
Dec 31, 2011
Timon Gehr
Jan 01, 2012
Chad J
Jan 01, 2012
Timon Gehr
Jan 01, 2012
Chad J
Jan 01, 2012
a
Jan 01, 2012
Timon Gehr
Jan 01, 2012
Chad J
Jan 01, 2012
Timon Gehr
Jan 01, 2012
Chad J
Jan 01, 2012
Timon Gehr
Jan 01, 2012
Chad J
Jan 01, 2012
Timon Gehr
Jan 02, 2012
Chad J
Dec 28, 2011
Artur Skawina
Dec 28, 2011
Gor Gyolchanyan
Dec 28, 2011
mta`chrono
Dec 28, 2011
Ali Çehreli
Dec 28, 2011
Ali Çehreli
Dec 28, 2011
Peter Alexander
Dec 28, 2011
Jakob Ovrum
Dec 28, 2011
Jonathan M Davis
Dec 28, 2011
Jakob Ovrum
Dec 28, 2011
Jonathan M Davis
Dec 29, 2011
deadalnix
Dec 29, 2011
Jonathan M Davis
Dec 28, 2011
Walter Bright
Dec 28, 2011
Timon Gehr
Dec 28, 2011
Peter Alexander
Dec 28, 2011
Sean Kelly
Dec 28, 2011
Dejan Lekic
Dec 28, 2011
Gor Gyolchanyan
Dec 28, 2011
so
Dec 30, 2011
mta`chrono
December 28, 2011
string is immutable(char)[]

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.

This is quite irritating because "string" is the most convenient and intuitive thing to type. I often get into situations where I've written a function that takes a string, and then I can't call it because all I have is a char[]. I could copy the char[] into a new string, but that's expensive, and I'd rather I could just call the function.

I think it's telling that most Phobos functions use 'const(char)[]' or 'in char[]' instead of 'string' for their arguments. The ones that use 'string' are usually using it unnecessarily and should be fixed to use const(char)[].

In an ideal world I'd much prefer if string was an alias for const(char)[], but string literals were immutable(char)[]. It would require a little more effort when dealing with concurrency, but that's a price I would be willing to pay to make the string alias useful in function parameters.
December 28, 2011
Peter Alexander:

> I often get into situations where I've written a function that takes a string, and then I can't call it because all I have is a char[].

I suggest you to show some of such situations.


> I think it's telling that most Phobos functions use 'const(char)[]' or 'in char[]' instead of 'string' for their arguments. The ones that use 'string' are usually using it unnecessarily and should be fixed to use const(char)[].

What are the Phobos functions that unnecessarily accept a string?

Bye,
bearophile
December 28, 2011
I agree, the string parameters are indeed irritating, but changing the alias would bring much more pain, then it would relieve.

On Wed, Dec 28, 2011 at 4:06 PM, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> string is immutable(char)[]
>
> 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.
>
> This is quite irritating because "string" is the most convenient and intuitive thing to type. I often get into situations where I've written a function that takes a string, and then I can't call it because all I have is a char[]. I could copy the char[] into a new string, but that's expensive, and I'd rather I could just call the function.
>
> I think it's telling that most Phobos functions use 'const(char)[]' or 'in char[]' instead of 'string' for their arguments. The ones that use 'string' are usually using it unnecessarily and should be fixed to use const(char)[].
>
> In an ideal world I'd much prefer if string was an alias for const(char)[], but string literals were immutable(char)[]. It would require a little more effort when dealing with concurrency, but that's a price I would be willing to pay to make the string alias useful in function parameters.



-- 
Bye,
Gor Gyolchanyan.
December 28, 2011
On 28/12/11 12:42 PM, bearophile wrote:
> Peter Alexander:
>
>> I often get into situations where I've written
>> a function that takes a string, and then I can't call it because all I
>> have is a char[].
>
> I suggest you to show some of such situations.

Any time you want to create a string without allocating memory.

char[N] buffer;
// write into buffer
// try to use buffer as string


>> I think it's telling that most Phobos functions use 'const(char)[]' or
>> 'in char[]' instead of 'string' for their arguments. The ones that use
>> 'string' are usually using it unnecessarily and should be fixed to use
>> const(char)[].
>
> What are the Phobos functions that unnecessarily accept a string?

Good question. I can't see any just now, although I have come across some in the past. Perhaps they have already been fixed.



December 28, 2011
Peter Alexander:

> Any time you want to create a string without allocating memory.
> 
> char[N] buffer;
> // write into buffer
> // try to use buffer as string

I have discussed a bit two or three times about this topic. In a post I even did suggest the idea of "scoped immutability", that was not appreciated. Generally creating immutable data structures is a source of troubles in all languages, and in D it's not a much solved problem yet.

In D today you are sometimes able to rewrite that as:

string foo(in int n) pure {
    auto buffer = new char[n];
    // write into buffer
    return buffer;
}
void bar(string s) {}
void main() {
    string s = foo(5);
    bar(s); // use buffer as string
}

Bye,
bearophile
December 28, 2011
I understand your intention. It was one of the main irritations when I moved to D. Here is a function that unnecessarily uses string.

/**
 * replaces foo by bar within text.
 */
string replace(string text, string foo, string bar)
{
   // ...
}

The function is crap because it can't be called with mutable char[].
Okay, that's true. Therefore you'd suggested to alias const(char)[]
instead of immutable(char)[] ???

But I think inout() is your man in this case. If I remeber correctly, it
has been fixed recently.

I'm not quite sure if I got your point. So forgive me if I was wrong.

December 28, 2011
On 28/12/11 1:27 PM, bearophile wrote:
> Peter Alexander:
>
>> Any time you want to create a string without allocating memory.
>>
>> char[N] buffer;
>> // write into buffer
>> // try to use buffer as string
>
> I have discussed a bit two or three times about this topic. In a post I even did suggest the idea of "scoped immutability", that was not appreciated. Generally creating immutable data structures is a source of troubles in all languages, and in D it's not a much solved problem yet.
>
> In D today you are sometimes able to rewrite that as:
>
> string foo(in int n) pure {
>      auto buffer = new char[n];
>      // write into buffer
>      return buffer;
> }
> void bar(string s) {}
> void main() {
>      string s = foo(5);
>      bar(s); // use buffer as string
> }
>
> Bye,
> bearophile

That only works when you allocate memory for the string, which is what I would like to avoid.
December 28, 2011
On 12/28/2011 04:06 AM, Peter Alexander wrote:
> string is immutable(char)[]
>
> 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.
>
> This is quite irritating because "string" is the most convenient and
> intuitive thing to type. I often get into situations where I've written
> a function that takes a string, and then I can't call it because all I
> have is a char[]. I could copy the char[] into a new string, but that's
> expensive, and I'd rather I could just call the function.
>
> I think it's telling that most Phobos functions use 'const(char)[]' or
> 'in char[]' instead of 'string' for their arguments. The ones that use
> 'string' are usually using it unnecessarily and should be fixed to use
> const(char)[].
>
> In an ideal world I'd much prefer if string was an alias for
> const(char)[], but string literals were immutable(char)[]. It would
> require a little more effort when dealing with concurrency, but that's a
> price I would be willing to pay to make the string alias useful in
> function parameters.

Agreed. I've talked about this in D.learn a number of times myself.

Ali

December 28, 2011
On 12/28/11 6:06 AM, Peter Alexander wrote:
> string is immutable(char)[]
>
> 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.
>
> This is quite irritating because "string" is the most convenient and
> intuitive thing to type. I often get into situations where I've written
> a function that takes a string, and then I can't call it because all I
> have is a char[]. I could copy the char[] into a new string, but that's
> expensive, and I'd rather I could just call the function.
>
> I think it's telling that most Phobos functions use 'const(char)[]' or
> 'in char[]' instead of 'string' for their arguments. The ones that use
> 'string' are usually using it unnecessarily and should be fixed to use
> const(char)[].
>
> In an ideal world I'd much prefer if string was an alias for
> const(char)[], but string literals were immutable(char)[]. It would
> require a little more effort when dealing with concurrency, but that's a
> price I would be willing to pay to make the string alias useful in
> function parameters.

I'm afraid you're wrong here. The current setup is very good, and much better than one in which "string" would be an alias for const(char)[].

The problem is escaping. A function that transitorily operates on a string indeed does not care about the origin of the string, but storing a string inside an object is a completely different deal. The setup

class Query
{
    string name;
    ...
}

is safe, minimizes data copying, and never causes surprises to anyone ("I set the name of my query and a little later it's all messed up!").

So immutable(char)[] is the best choice for a correct string abstraction compared against both char[] and const(char)[]. In fact it's in a way good that const(char)[] takes longer to type, because it also carries larger liabilities.

If you want to create a string out of a char[] or const(char)[], use std.conv.to or the unsafe assumeUnique.


Andrei
December 28, 2011
On 12/28/11 13:42, bearophile wrote:
> Peter Alexander:
> 
>> I often get into situations where I've written a function that takes a string, and then I can't call it because all I have is a char[].
> 
> I suggest you to show some of such situations.
> 
> 
>> I think it's telling that most Phobos functions use 'const(char)[]' or 'in char[]' instead of 'string' for their arguments. The ones that use 'string' are usually using it unnecessarily and should be fixed to use const(char)[].
> 
> What are the Phobos functions that unnecessarily accept a string?

eg things like std.demangle? (which wraps core.demangle and that one accepts const(char)[]). IIRC eg the stdio functions taking file names want strings too; never investigated if they really need this, just .iduped the args...
In general, a lot of things break when trying to switch to "proper" const(char)[] in apps, usually because the app itself used "string" instead of the const version, but fixing it up often also uncovers lib API issues.

artur
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11