On Tue, 02 Oct 2012 15:35:47 -0400, David Nadlinger <see@klickverbot.at> wrote:

> On Tuesday, 2 October 2012 at 19:34:31 UTC, David Nadlinger wrote:
>> Well, make it to!char(char*) then! ;)
>
> Oh dear, this doesn't get better: Of course, I've meant to write »to!(char[])(char*)«.

Right.  I agree, this should not allocate (I think someone said it does, but it's probably not necessary to).

But still, what looks better?

auto x = SomeSystemCallThatReturnsACString();

writefln("%s", to!(char[])(x));
writefln("%s", zstr(x));

I want something easy to type, and not too difficult to visually parse.

In fact, a better solution would be to define a C string type (other than char *), and just pretend those system calls return that.  Then support that C string type in writef.

-Steve

On 10/2/12, Walter Bright <newshound1@digitalmars.com> wrote:
> On 9/30/2012 11:31 AM, deadalnix wrote:
>> If you know that a string is 0 terminated, you can easily create a slice from it as follow :
>>
>> char* myZeroTerminatedString;
>> char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)];
> Since %zs is inherently unsafe, it
> hides such unsafety in a commonly used library function, which will
> infect everything else that transitively calls writefln with unsafety.
>
> This makes %zs an unacceptable feature.

How does it hide anything if you have to explicitly mark the format specifier as %zs? It would be documented, just like it's documented that passing pointers to garbage-collected memory to the C side is inherently unsafe.

> deadalnix's example shows that adding a new format specifier %zs adds little value.

It adds convenience, which is an important trait in this day and age. If that's not a concern, why is printf a symbol you can get your hands on as soon as you import std.stdio? And if safety is a concern why is printf used in Phobos at all? I count 427 lines of printf calls in Phobos and 843 lines in Druntime (druntime might have a good excuse since it shouldn't import Phobos functions). Many of these calls in Phobos are not simple D string literal printf calls either.

Btw, some weeks ago when dstep was announced you were jumping for joy and were instantly proposing language changes to add better support for wrapping C. But asking for better library support is somehow controversial. I don't understand the double-standard.

On Tuesday, 2 October 2012 at 21:30:35 UTC, Andrej Mitrovic wrote:
> On 10/2/12, Walter Bright <newshound1@digitalmars.com> wrote:
>> On 9/30/2012 11:31 AM, deadalnix wrote:
>>> If you know that a string is 0 terminated, you can easily create a slice
>>> from it as follow :
>>>
>>> char* myZeroTerminatedString;
>>> char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)];
>> Since %zs is inherently unsafe, it
>> hides such unsafety in a commonly used library function, which will
>> infect everything else that transitively calls writefln with unsafety.
>>
>> This makes %zs an unacceptable feature.
>
> How does it hide anything if you have to explicitly mark the format
> specifier as %zs? It would be documented, just like it's documented
> that passing pointers to garbage-collected memory to the C side is
> inherently unsafe.

writefln cannot be @safe if it has to support an unsafe format specifier. It's "hidden" because it affects every call to writefln, even if it doesn't use the unsafe format specifier.

On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> writefln cannot be @safe if it has to support an unsafe format specifier. It's "hidden" because it affects every call to writefln, even if it doesn't use the unsafe format specifier.

Ah damn I completely forgot about @safe. I tend to avoid recent features..

OK then I think my arguments are moot. Nevertheless I can always define a helper function for my own purposes I guess.

Sorry Walter for not taking @safe into account. :)

On Wed, Oct 03, 2012 at 03:07:14AM +0200, Andrej Mitrovic wrote:
> On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> > writefln cannot be @safe if it has to support an unsafe format specifier. It's "hidden" because it affects every call to writefln, even if it doesn't use the unsafe format specifier.
[...]

Hmm, this seems to impose unnecessary limitations on @safe. I guess the current language doesn't allow for a "conditionally-safe" tag where something can be implicitly marked @safe if it's provable at compile-time that it's safe?


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

On Tuesday, October 02, 2012 18:21:30 H. S. Teoh wrote:
> On Wed, Oct 03, 2012 at 03:07:14AM +0200, Andrej Mitrovic wrote:
> > On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> > > writefln cannot be @safe if it has to support an unsafe format specifier. It's "hidden" because it affects every call to writefln, even if it doesn't use the unsafe format specifier.
> 
> [...]
> 
> Hmm, this seems to impose unnecessary limitations on @safe. I guess the current language doesn't allow for a "conditionally-safe" tag where something can be implicitly marked @safe if it's provable at compile-time that it's safe?

The format string is a runtime argument, so nothing can be proven about it at compile time.

If you want any kind of @safe inferrence, you need to use a template. If writefln took the format string as a template argument and generated different code (which was @safe or not depending on what it did) based on what was in the format string, then inferrence could take place, but otherwise no.

- Jonathan M Davis

On Tue, Oct 02, 2012 at 07:50:09PM -0700, Jonathan M Davis wrote:
> On Tuesday, October 02, 2012 18:21:30 H. S. Teoh wrote:
> > On Wed, Oct 03, 2012 at 03:07:14AM +0200, Andrej Mitrovic wrote:
> > > On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> > > > writefln cannot be @safe if it has to support an unsafe format specifier. It's "hidden" because it affects every call to writefln, even if it doesn't use the unsafe format specifier.
> > 
> > [...]
> > 
> > Hmm, this seems to impose unnecessary limitations on @safe. I guess the current language doesn't allow for a "conditionally-safe" tag where something can be implicitly marked @safe if it's provable at compile-time that it's safe?
> 
> The format string is a runtime argument, so nothing can be proven about it at compile time.
> 
> If you want any kind of @safe inferrence, you need to use a template. If writefln took the format string as a template argument and generated different code (which was @safe or not depending on what it did) based on what was in the format string, then inferrence could take place, but otherwise no.
[...]

Yes that's what I mean. If the format string is known at compile-time
and known to involve only @safe code, then this would work. Something
like this might work if CTFE is used to parse the format string
piecemeal (i.e., translate something like writefln("%d %s",x,y) into
write!int(x); write!string(" "); write!string(y)). The safe instances of
write!T(...) will be marked @safe. But it does seem like a lot of work
just so we can use @safe, though. I suppose we could just use @trusted
and call it a day.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine

On Wednesday, 3 October 2012 at 05:04:01 UTC, H. S. Teoh wrote:
> Yes that's what I mean. If the format string is known at compile-time
> and known to involve only @safe code, then this would work. Something
> like this might work if CTFE is used to parse the format string
> piecemeal (i.e., translate something like writefln("%d %s",x,y) into
> write!int(x); write!string(" "); write!string(y)). The safe instances of
> write!T(...) will be marked @safe.

It doesn't matter if the argument is known at compile-time or not, because there's no way to know that without receiving the format string as a template parameter, in which case it must *always* be known at compile-time (runtime format string would not be supported), and then the syntax is no longer writefln("%d %s", x, y). Obviously, such a change is not acceptable.

> I suppose we could just use @trusted
> and call it a day.

No, that would be abusing @trusted. The function would no longer be safe, *because it contains possibly unsafe code*. @trusted is for safe functions that the compiler cannot prove safe.

On Wednesday, October 03, 2012 07:35:23 Jakob Ovrum wrote:
> > I suppose we could just use @trusted
> > and call it a day.
> 
> No, that would be abusing @trusted. The function would no longer be safe, *because it contains possibly unsafe code*. @trusted is for safe functions that the compiler cannot prove safe.

Yeah. You basically _never_ just mark @trusted and call it a day. You only mark something @trusted if you've verified that _everything_ that that function does which is @system is done in a way that's ultimately @safe. In particular, marking much of anything which is templated as @trusted is almost always just plain wrong.

- Jonathan M Davis

On Tue, 02 Oct 2012 21:44:11 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> In fact, a better solution would be to define a C string type (other than char *), and just pretend those system calls return that.  Then support that C string type in writef.
>
> -Steve

:D
http://comments.gmane.org/gmane.comp.lang.d.general/97793

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