On 15-05-2012 19:29, Gor Gyolchanyan wrote:
>  >> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen <alex@lycus.org
> <mailto:alex@lycus.org>> wrote:
>  >> Nope. write* perform GC allocation.
>
> 1. Give me the top 3 use cases, where GC allocation is intolerable when
> writing to an output stream.

Who the hell am I or you to dictate use cases? But a few off the top of my head:

1) Building without a GC *at all* (and yes, it is possible).
2) When writing high performance tools for doing UNIX-style program output piping.

> 2. writef and friends could get cousins like nogcwritef and
> nogcwritefln. (see comments beloaw)

Patches welcome.

> 3. GC can be turned off and gc-allocated memory can be GC.freeed.

Yes, if you alter the implementation. You can't free it from the call site. Again, patches welcome.

> 4. printf could get wrapped to take d-strings by malloc-ing new buffers
> for the c-strings if necessary.

And just about every C function taking strings, ever. This is a bad strategy, and makes D's C interoperability worse.

>
>  >> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen <alex@lycus.org
> <mailto:alex@lycus.org>> wrote:
>  >> You're assuming everyone uses Phobos. This is not the case.
>
> I'm assuming everyone is sane, because Phobos is called "the standard
> library" for a damned good reason. For those who don't - they're welcome
> to use whatever they want and convert d-strings to c-strings any way
> they choose if necessary.

Yes, let's cripple a systems language for the comfort of the non-systems programmers. Excellent idea.

>
> --
> Bye,
> Gor Gyolchanyan.

PS: Removing null-terminated string literals is not going to fix the array slice corner cases by itself. I think this discussion is fairly pointless. If you want to fix slices, go all the way with it, not just half the way.

Besides, this is probably not going to change anyway. We're focusing on stabilizing the language, not changing it.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 05/15/2012 06:45 PM, deadalnix wrote:
> Le 15/05/2012 17:51, Christophe a écrit :
>> deadalnix , dans le message (digitalmars.D:167404), a écrit :
>>> This looks to me like a bad practice. C string and D string are
>>> different beasts, and we have toStringz .
>>
>> C string and D string are different, but it's not a bad idea to have
>> string *literals* that works for both C and D strings, otherwise using
>> printf will lead to a bug each time the programmer forget the trailing
>> \0.
>>
>>> It is kind of dumb to create a WAT is the language because druntime dev
>>> did mistakes. It have to be fixed.
>>
>> You can't rely on an empty string to be null since you must be able to
>> reserve place at the end of the array, and or the string could be the
>> result of poping a full string.
>
> This is why I stated put null when the string length is SET to 0, not
> when it is 0.
>
> So it is nulled when I create an empty slice, or do arr.length = 0

Might as well start Microsoft Flight Simulator when the length is set to 9797.

If you want to clear the contents of the array, use arr=null or arr=[].

On Tue, May 15, 2012 at 11:46 AM, deadalnix <deadalnix@gmail.com> wrote:

> Le 15/05/2012 18:19, Gor Gyolchanyan a écrit :
>
>>
>>
>> On Tue, May 15, 2012 at 7:51 PM, Christophe
>> <travert@phare.normalesup.org <mailto:travert@phare.**normalesup.org<travert@phare.normalesup.org>>>
>> wrote:
>>
>>    using printf will lead to a bug each time the programmer forget the
>>    trailing
>>    \0.
>>
>>
>> First of all, printf shouldn't be used! There's writef and it's superior
>> to printf in any way!
>> Second of all, if the zero-termination of literals are to be removed,
>> the literals will no longer be accepted as a pointer to a character.
>> The appropriate type mismatch error will force the user to use toUTF8z
>> to get ht e zero-terminated utf-8 version of the original string.
>> In case it's a literal, one could use the compile-time version of
>> toUTF8z to avoid run-time overhead.
>> This all doesn't sound like a bad idea to me. I don't see any security
>> or performance flaws in this scheme.
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> May god ear you !
>

Unfortunately, using writef/writefln would make DRuntime depend on Phobos, which is unacceptable.

Le 15/05/2012 21:57, Andrew Wiley a écrit :
> On Tue, May 15, 2012 at 11:46 AM, deadalnix <deadalnix@gmail.com
> <mailto:deadalnix@gmail.com>> wrote:
>
>     Le 15/05/2012 18:19, Gor Gyolchanyan a écrit :
>
>
>
>         On Tue, May 15, 2012 at 7:51 PM, Christophe
>         <travert@phare.normalesup.org
>         <mailto:travert@phare.normalesup.org>
>         <mailto:travert@phare.__normalesup.org
>         <mailto:travert@phare.normalesup.org>>> wrote:
>
>             using printf will lead to a bug each time the programmer
>         forget the
>             trailing
>             \0.
>
>
>         First of all, printf shouldn't be used! There's writef and it's
>         superior
>         to printf in any way!
>         Second of all, if the zero-termination of literals are to be
>         removed,
>         the literals will no longer be accepted as a pointer to a character.
>         The appropriate type mismatch error will force the user to use
>         toUTF8z
>         to get ht e zero-terminated utf-8 version of the original string.
>         In case it's a literal, one could use the compile-time version of
>         toUTF8z to avoid run-time overhead.
>         This all doesn't sound like a bad idea to me. I don't see any
>         security
>         or performance flaws in this scheme.
>         --
>         Bye,
>         Gor Gyolchanyan.
>
>
>     May god ear you !
>
>
> Unfortunately, using writef/writefln would make DRuntime depend on
> Phobos, which is unacceptable.
>

druntime isn't supposed to printf stuff.

Le 15/05/2012 20:34, Alex Rønne Petersen a écrit :
> Besides, this is probably not going to change anyway. We're focusing on
> stabilizing the language, not changing it.
>

This always have been a design mistake to auto cast array in pointers. This is silent fallback to usafe world, and what we want to avoid.

This has no benefit because using .ptr isn't really complex and make the transition obvious.

This has been raised many time in the past as being an issue, and it fit nicely here.

Having \0 terminated string in D were it has no usage is quite dumb.

Le 15/05/2012 17:51, Christophe a écrit :
> deadalnix , dans le message (digitalmars.D:167404), a écrit :
>> This looks to me like a bad practice. C string and D string are
>> different beasts, and we have toStringz .
>
> C string and D string are different, but it's not a bad idea to have
> string *literals* that works for both C and D strings, otherwise using
> printf will lead to a bug each time the programmer forget the trailing
> \0.
>

Due to slicing, it is already unsafe to pass a D string to C code. The main problem is array casting silently to pointers, making the error easy to do.

Fixing the problem for literal isn't going to solve it at all.

The real solution is toStringz

On 05/16/2012 12:29 AM, deadalnix wrote:
> Le 15/05/2012 20:34, Alex Rønne Petersen a écrit :
>> Besides, this is probably not going to change anyway. We're focusing on
>> stabilizing the language, not changing it.
>>
>
> This always have been a design mistake to auto cast array in pointers.
> This is silent fallback to usafe world, and what we want to avoid.
>

Getting a pointer to the beginning of a zero-terminated string literal is perfectly safe.

> This has no benefit because using .ptr isn't really complex and make the
> transition obvious.
>
> This has been raised many time in the past as being an issue, and it fit
> nicely here.
>

This is a compile time error:

int[] arr;
int* p=arr;

What exactly are you asking for?

> Having \0 terminated string in D were it has no usage is quite dumb.

What you don't seem to get is that it actually has usage.

On Tue, 15 May 2012 04:42:10 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 14/05/2012 21:53, Steven Schveighoffer a écrit :
>> On Mon, 14 May 2012 15:30:25 -0400, deadalnix <deadalnix@gmail.com> wrote:
>>
>>> Le 14/05/2012 16:37, Steven Schveighoffer a écrit :
>>>> Note that [] is a request to the runtime to build an empty array. The
>>>> runtime detects this, and rather than consuming a heap allocation to
>>>> build nothing, it simply returns a null-pointed array. This is 100% the
>>>> right decision, and I don't think anyone would ever convince me (or
>>>> Andrei or Walter) otherwise.
>>>>
>>>
>>> Obviously this is the right thing to do !
>>>
>>> The question is why an array of length 0 isn't nulled ? It lead to
>>> confusing semantic here, and can keep alive memory that can't be
>>> accessed.
>>
>> int[] arr;
>> arr.reserve(10000);
>> assert(arr.length == 0);
>>
>> -Steve
>
> The length isn't set to 0 here. You obviously don't want that to be nulled.

The assert disagrees with you :)

-Steve

On Mon, 14 May 2012 18:07:24 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 05/14/2012 01:51 PM, deadalnix wrote:
>> Le 14/05/2012 12:49, Gor Gyolchanyan a écrit :
>>> So, null arrays and empty arrays are always the same, except for an
>>> empty string, which is a valid non-nill array of characters with length
>>> 0, right?
>>>
>>
>> If it is the current behavior, it deserve a WAT !
>
> I agree, but it is explained easily. Built-in string literals are always zero-terminated, therefore an empty string literal must point into accessible memory. I'd like to have [] !is null as well, so that null can reliably be used as a sentinel value.

This would mean either a) allocating memory for a 0 length array, or b) pointing it at non-null but non-heap memory.

a) is certainly out of the question.

b) is possible, but I still think we should discourage using null as a sentinel, it leads to confusing code.

Regardless, we should fix if(!arr) to mean if(!arr.length).

-Steve

On Tue, 15 May 2012 18:31:26 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 15/05/2012 17:51, Christophe a écrit :
>> deadalnix , dans le message (digitalmars.D:167404), a écrit :
>>> This looks to me like a bad practice. C string and D string are
>>> different beasts, and we have toStringz .
>>
>> C string and D string are different, but it's not a bad idea to have
>> string *literals* that works for both C and D strings, otherwise using
>> printf will lead to a bug each time the programmer forget the trailing
>> \0.
>>
>
> Due to slicing, it is already unsafe to pass a D string to C code. The main problem is array casting silently to pointers, making the error easy to do.

How so?  strings are immutable, and literals are *truly* immutable.

> Fixing the problem for literal isn't going to solve it at all.
>
> The real solution is toStringz

toStringz can allocate a new block in order to ensure 0 gets added.  This is ludicrous!

You are trying to tell me that any time I want to call a C function with a string literal, I have to first heap-allocate it, even though I *know* it's safe.

I don't see a "problem" anywhere.  The current system is perfect for what it needs to do.

-Steve