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 <jakobov...@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
