Am 16.06.2011 14:56, schrieb Mike Parker:
> On 6/16/2011 7:59 PM, Daniel Gibson wrote:
>> Am 16.06.2011 13:01, schrieb Kagamin:
>>> c_str
>>> c_wstr
>>>
>>> similarly to c_long
>>
>> 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.

On Jun 16, 11 14:30, Jonathan M Davis wrote:
> Okay. I have an open pull request whose main goal is to rename various string
> and character functions so that they're properly camelcased (as has been
> discussed previous in this group): https://github.com/D-Programming-
> Language/phobos/pull/101
>
> All in all, I think that the renaming in there is fairly obvious and non-
> controversial. However, we have the problem of std.string.toStringz. toStringz
> isn't properly camelcased (at least, _I_ would definitely argue that it
> isn't). Currently (in that pull request), I have it renamed to toStringZ (with
> the old version still around and scheduled to be deprecated, so no code would
> break immediately if it were merged in). But some have said that they consider
> toStringz to be properly camelcased (apparently they view stringz as a special
> word indicating a zero-terminated string). Another suggestion was to rename it
> to toCString (which is arguably much more obvious for newbies). In addition to
> that, we have std.utf.toUTF16z, which matches the naming scheme that toStringz
> has, so if we rename toStringz, we should probably rename toUTF16z as well (to
> toWCString?). Certainly, there's no consensus on what to do with the name of
> toStringz.
>
> Now, toStringz is probably one of the most heavily used string functions in
> Phobos. If we rename it, a _lot_ of code is going to have to be changed. So,
> if we rename it, we need to give it a name which most people would consider
> better than toStringz and worth the consistency that we gain with regards to
> the naming of functions in Phobos. So, the question is, should we
>
> 1. Keep toStringz as it is (as well as toUTF16z) and either consider stringz
> to be some sort of word unique to the D community or just admit that we're not
> going to camelcase it because it would break too much code to do so.
>
> 2. Just camelcase it properly and rename it to toStringZ (and probably rename
> toUTF16z to toUTF16Z). Code will have to be changed, but the function is still
> immediately recognizable to long time D programmers.
>
> 3. Rename it to toCString (probably renaming toUTF16z to something like
> toWCString), so it's then more recognizable to newbies, but it'll take some
> getting used to for everyone else (and of course require lots of code to be
> changed).
>
> 4. Rename toStringz to something else which is properly camelcased.
>
> I don't like leaving toStringz as it is because of its casing, but I also
> don't want to cause code breakage without general agreement on the replacement
> name. It's just too important of a function to change the name of willy-nilly.
> So, I'm looking to see what everyone else thinks.
>
> Thoughts? Opinions?
>
> - Jonathan M Davis

+1 toCString
+0 toStringz
-1 toStringZ & toUTF16Z

Timon Gehr 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.
> >
> > Cheers,
> > - Daniel
> 
> +1. But make it 'toCWString'. :o)
> 
> Timon

+1

On Thu, 16 Jun 2011 04:47:50 -0400, Dejan Lekic <dejan.lekic@tiscali.co.uk> wrote:

> I am against the change for ... social reasons.
>
> Simply put, the D community is used to toStringz . I might be wrong, but I think we are all familiar with this function and use it on a daily basis. :)

I agree with this assessment.  I'll add that toStringz is memorable -- I remember how to use it and write it instantly.  I'm not sure why, but I think it's because it's name is really unlikely to occur in any other context.

I don't agree that toStringz is incorrectly camel cased, and I think toCString is not as descriptive, because it's identifying the language where zero-terminated strings are from, not that the string is zero terminated (signified well by the zero).

I would like to change toUTF16z to toWStringz (and likewise for dstrings).  You haven't listed this as an option.  I see a large inconsistency there.

-Steve

On Wed, 15 Jun 2011 23:30:03 -0700, Jonathan M Davis wrote:

> Okay. I have an open pull request whose main goal is to rename various string and character functions so that they're properly camelcased (as has been discussed previous in this group): https://github.com/D-Programming- Language/phobos/pull/101
> 
> All in all, I think that the renaming in there is fairly obvious and non- controversial. However, we have the problem of std.string.toStringz. [...]

As I said in the pull request, I'd like to keep toStringz the way it is.

-Lars

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).

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;

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Am 16.06.2011 16:33, schrieb Steven Schveighoffer:
> On Thu, 16 Jun 2011 04:47:50 -0400, Dejan Lekic
> <dejan.lekic@tiscali.co.uk> wrote:
>
>> I am against the change for ... social reasons.
>>
>> Simply put, the D community is used to toStringz . I might be wrong,
>> but I think we are all familiar with this function and use it on a
>> daily basis. :)
>
> I agree with this assessment. I'll add that toStringz is memorable -- I
> remember how to use it and write it instantly. I'm not sure why, but I
> think it's because it's name is really unlikely to occur in any other
> context.
>
> I don't agree that toStringz is incorrectly camel cased, and I think
> toCString is not as descriptive, because it's identifying the language
> where zero-terminated strings are from, not that the string is zero
> terminated (signified well by the zero).
>
> I would like to change toUTF16z to toWStringz (and likewise for
> dstrings). You haven't listed this as an option. I see a large
> inconsistency there.
I completely agree!

>
> -Steve

I think stringz is a name as itself and then having a camel-cased toStringX is correct IMO.

On 2011-06-16 07:33, Steven Schveighoffer wrote:
> On Thu, 16 Jun 2011 04:47:50 -0400, Dejan Lekic
> 
> <dejan.lekic@tiscali.co.uk> wrote:
> > I am against the change for ... social reasons.
> > 
> > Simply put, the D community is used to toStringz . I might be wrong, but I think we are all familiar with this function and use it on a daily basis. :)
> 
> I agree with this assessment.  I'll add that toStringz is memorable -- I remember how to use it and write it instantly.  I'm not sure why, but I think it's because it's name is really unlikely to occur in any other context.
> 
> I don't agree that toStringz is incorrectly camel cased

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.

> and I think
> toCString is not as descriptive, because it's identifying the language
> where zero-terminated strings are from, not that the string is zero
> terminated (signified well by the zero).
> 
> I would like to change toUTF16z to toWStringz (and likewise for dstrings).  You haven't listed this as an option.  I see a large inconsistency there.

Well, my concern at this point is really toStringz, not toUTF16z. If toStringz is renamed, then toUTF16z should follow suit. If it isn't, then perhaps toUTF16z should still be renamed, but my pull request doesn't do much with std.utf, so messing with toUTF16z isn't really the goal. It's just a side effect of renaming toStringz. So, if we keep toStringz, we may very well still rename toUTF16z, but the real question is whether we want to rename toStringz.

- Jonathan M Davis

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.

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