On 2011-06-16 09:21, Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > I'm afraid that I don't understand this view at all, given that string is a word and stringz isn't, though there are a few people that have expressed this view now.
> 
> If we had a function for to!ulong in this style, would you call it toULong or toUlong?
> 
> I'd expect the latter - the word is "ulong", a single unit, not "U Long".
> 
> D1 also did it this way: http://digitalmars.com/d/1.0/phobos/std_conv.html

I'd probably end up calling it to ULong, since U stands for unsigned and it looks a lot better that way, but since ulong is a type name, I could easily see it being named toUlong.

However, I don't see what that has to do with toStringz. stringz is neither a type nor a word. The _only_ place that stringz is used AFAIK is in the name toStringz, where the zero presumably stands for zero, as in zero-terminated string. If stringz were a type in D, then yeah, toStringz would be properly camelcased, but stringz isn't a type.

- Jonathan M Davis

On 16.06.2011 20:07, KennyTM~ wrote:
> On Jun 16, 11 23:09, Regan Heath wrote:
>> On Thu, 16 Jun 2011 13:00:23 +0100, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>
>>> Daniel Gibson wrote:
>>>> Am 16.06.2011 08:30, schrieb Jonathan M Davis:
>>>>
>>>>>
>>>>> 3. Rename it to toCString (probably renaming toUTF16z to something like
>>>>> toWCString), so it's then more recognizable to newbies
>>>>
>>>> This + keep around aliases for the old names until D3.
>>
>> +1
>>
>>> +1. But make it 'toCWString'. :o)
>>
>> Or toWString (looks nicer to me).
>>
>
> A potential problem is that an immutable(wchar)[] is wstring.
>
>> Or toCStr and toWStr (to save 3 characters on each).
>>
>> winnt.h defines many similar types:
>>
>> typedef __nullterminated WCHAR *NWPSTR, *LPWSTR, *PWSTR;
>> typedef __nullterminated PWSTR *PZPWSTR;
>> typedef __nullterminated CONST PWSTR *PCZPWSTR;
>> typedef __nullterminated WCHAR UNALIGNED *LPUWSTR, *PUWSTR;
>> typedef __nullterminated CONST WCHAR *LPCWSTR, *PCWSTR;
>> typedef __nullterminated PCWSTR *PZPCWSTR;
>> typedef __nullterminated CONST WCHAR UNALIGNED *LPCUWSTR, *PCUWSTR;
>>
>> so variations on any of those make sense.
>>
>> .. I think the toStringz probably came from the winnt.h defines using z..
>>
>> typedef __nullterminated CHAR *NPSTR, *LPSTR, *PSTR;
>> typedef __nullterminated PSTR *PZPSTR;
>> typedef __nullterminated CONST PSTR *PCZPSTR;
>> typedef __nullterminated CONST CHAR *LPCSTR, *PCSTR;
>> typedef __nullterminated PCSTR *PZPCSTR;
>>
>
> Stringz means "Z"ero-terminated "String". The usage predates Windows NT.

I suspect it's original name was Z-string and indeed it's usage started much earlier (e.g. it was used in PC BIOS).
To be more precise there was notation for ACSII string that comes form having two types of strings:
L-string  - Length is in first byte (so up 255 characters)
Z-string - Zero byte at the end. (or ASCIIZ)

Anyway I could live with any of  toStringz, toZString, toStringZ, toCString.

-- 
Dmitry Olshansky

Daniel Gibson Wrote:

> > It's not a conversion function, but an alias. It's declared, along with c_ulong, in core.stdc.config.
> 
> So it has nothing to do with toStringz and similar names would be confusing.

Not for c++ people.

Daniel Gibson Wrote:

> >> So c_long converts a long to a c-long?
> >> (Is this a D function/type? I couldn't find it on the homepage)
> > 
> > It's not a conversion function, but an alias. It's declared, along with c_ulong, in core.stdc.config.
> 
> So it has nothing to do with toStringz and similar names would be confusing.

May be

struct c_str{}
to!c_str();

Am 16.06.2011 20:30, schrieb Kagamin:
> Daniel Gibson Wrote:
> 
>>>> So c_long converts a long to a c-long?
>>>> (Is this a D function/type? I couldn't find it on the homepage)
>>>
>>> It's not a conversion function, but an alias. It's declared, along with c_ulong, in core.stdc.config.
>>
>> So it has nothing to do with toStringz and similar names would be confusing.
> 
> May be
> 
> struct c_str{}
> to!c_str();

No.
The whole point of toStringz() is that it returns a string that can be
fed to normal C functions that work on strings.
And C functions expect a "string" to be a char* (or wchar*) pointing to
a block of memory containing the string and terminated by '\0'.
The functionality of toStringz() should not change.
This is just about the name.

Cheers,
- Daniel

Jonathan M Davis wrote:
> stringz is neither a type nor a word.

It *is* a word. A stringz is a string that ends in zero. This
family of traditional names (STRINGZ, ASCIZ, etc.) predates C itself.

On the other hand, there is *no such thing* as a StringZ. You'd never call it a "string zero". You'd call it a "zero terminated string", or maybe a "C string".

Changing it to "toCString" is completely pointless, a cost without a benefit, but at least it's not a completely nonsensical name like toStringZ.

On 2011-06-16 12:16, Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > stringz is neither a type nor a word.
> 
> It *is* a word. A stringz is a string that ends in zero. This
> family of traditional names (STRINGZ, ASCIZ, etc.) predates C itself.
> 
> On the other hand, there is *no such thing* as a StringZ. You'd never call it a "string zero". You'd call it a "zero terminated string", or maybe a "C string".
> 
> Changing it to "toCString" is completely pointless, a cost without a benefit, but at least it's not a completely nonsensical name like toStringZ.

Well, I'd argue that stringz is just as nonsensical as stringZ. I have _never_ heard the term stringz used outside of D. Searching for it online brings up _nothing_ (not even D). And I wouldn't really consider an identifier which is completely uppercase to necessarily say anything about where the beginning and end of a word is anyway, so I wouldn't really consider that much of a precedent. But it doesn't really matter.

What matters is whether we as a group think that renaming toStringz is worthwhile, and if so, what we name it to. _No one_ thus far has liked the name toStringZ, even if they agree that toStringz should be changed. They're pretty much all voting for toCString. So, there's no way that it's going to end up as toStringZ.

I'm going to let this thread go a bit longer before I decide what I'm going to do, but from the looks of it, we're not reaching any kind of consensus on this, and I'm not going to change toStringz unless we actually reach a consensus on the matter.

The discussions on fixing the function names in Phobos (and in particular, std.string) resulted in an almost unanimous decision to fix the function names in Phobos to be properly camelcased. So, in general, it's worth making those changes. However, this particular discussion about this particular function is anything but unanimous, so unless a greater agreement is reached than is currently happening, toStringz isn't going to be changed.

- Jonathan M Davis

Daniel Gibson Wrote:

> No.
> The whole point of toStringz() is that it returns a string that can be
> fed to normal C functions that work on strings.
> And C functions expect a "string" to be a char* (or wchar*) pointing to
> a block of memory containing the string and terminated by '\0'.
> The functionality of toStringz() should not change.
> This is just about the name.

Why don't you like to!c_str(); ?

Am 17.06.2011 09:03, schrieb Kagamin:
> Daniel Gibson Wrote:
> 
>> No.
>> The whole point of toStringz() is that it returns a string that can be
>> fed to normal C functions that work on strings.
>> And C functions expect a "string" to be a char* (or wchar*) pointing to
>> a block of memory containing the string and terminated by '\0'.
>> The functionality of toStringz() should not change.
>> This is just about the name.
> 
> Why don't you like to!c_str(); ?

What is to!c_str() supposed to return?

To be a useful alternative to toStringz() it needs to be

  char* to!c_str(string s) (or immutable(char)* or something)
i.e. the related toImpl looks like
  char* toImpl(c_str, string)(string s)
=> 3 types! (char*, c_str, string)

But the signature of toImpl is
  T toImpl(T, S)(S s)
so the related to's signature is
  T to(T)(S s)
or something like that.

This means, that the return type T is the same type you instantiate to
with.
That means to!c_str(string s) will return a c_str struct and not a char*
And, as I explained in my previous post, C functions want a char* not a
struct c_str.

Cheers,
- Daniel

On 17.06.2011 14:34, Daniel Gibson wrote:
> Am 17.06.2011 09:03, schrieb Kagamin:
>> Daniel Gibson Wrote:
>>
>>> No.
>>> The whole point of toStringz() is that it returns a string that can be
>>> fed to normal C functions that work on strings.
>>> And C functions expect a "string" to be a char* (or wchar*) pointing to
>>> a block of memory containing the string and terminated by '\0'.
>>> The functionality of toStringz() should not change.
>>> This is just about the name.
>> Why don't you like to!c_str(); ?
> What is to!c_str() supposed to return?
>
> To be a useful alternative to toStringz() it needs to be
>
>    char* to!c_str(string s) (or immutable(char)* or something)
> i.e. the related toImpl looks like
>    char* toImpl(c_str, string)(string s)
> =>  3 types! (char*, c_str, string)
>
> But the signature of toImpl is
>    T toImpl(T, S)(S s)
> so the related to's signature is
>    T to(T)(S s)
> or something like that.
>
> This means, that the return type T is the same type you instantiate to
> with.
> That means to!c_str(string s) will return a c_str struct and not a char*
> And, as I explained in my previous post, C functions want a char* not a
> struct c_str.
>
Fixable with alias this, but still I dislike this c_str artifact.
It looks like you are converting type, while all it does is ensuring that there is enough 0 bytes past the end of string.

-- 
Dmitry Olshansky