char[] fn()
{
  char ar[21];
  int    cch = sprintf(ar, "%d", 101);

  return ar[0 .. cch];
}

Does this return a slice into something that (no longer) exists on the stack, or does it allocated a new heap variable whose contents are equivalent to the sliced section of ar?

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bmqqet$dgb$1@digitaldaemon.com...
> char[] fn()
> {
>   char ar[21];
>   int    cch = sprintf(ar, "%d", 101);
>
>   return ar[0 .. cch];
> }
>
> Does this return a slice into something that (no longer) exists on the
> stack,

Yes.

> or does it allocated a new heap variable whose contents are equivalent to the sliced section of ar?

No. To do that:

    return ar[0..cch].dup;

Eeek! It makes sense, of course.

It's something that we'll need to make sure is well documented.

"Walter" <walter@digitalmars.com> wrote in message news:bmqv3c$lok$4@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bmqqet$dgb$1@digitaldaemon.com...
> > char[] fn()
> > {
> >   char ar[21];
> >   int    cch = sprintf(ar, "%d", 101);
> >
> >   return ar[0 .. cch];
> > }
> >
> > Does this return a slice into something that (no longer) exists on the
> > stack,
>
> Yes.
>
> > or does it allocated a new heap variable whose contents are equivalent to the sliced section of ar?
>
> No. To do that:
>
>     return ar[0..cch].dup;
>
>

"Walter" <walter@digitalmars.com> wrote in message news:bmqv3c$lok$4@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bmqqet$dgb$1@digitaldaemon.com...
> > char[] fn()
> > {
> >   char ar[21];
> >   int    cch = sprintf(ar, "%d", 101);
> >
> >   return ar[0 .. cch];
> > }
> >
> > Does this return a slice into something that (no longer) exists on the
> > stack,
>
> Yes.

Wouldn't the compiler try to catch errors like this at compile time?  Simple data flow.  Local variables cannot outlive the function, and cannot be used in a return statement, even indirectly.  Their values can be returned, however.  I guess you have to allow passing local variables to other functions as parameters..

Sean

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bmr28m$plk$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:bmqv3c$lok$4@digitaldaemon.com...
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bmqqet$dgb$1@digitaldaemon.com...
> > > char[] fn()
> > > {
> > >   char ar[21];
> > >   int    cch = sprintf(ar, "%d", 101);
> > >
> > >   return ar[0 .. cch];
> > > }
> > >
> > > Does this return a slice into something that (no longer) exists on the
> > > stack,
> >
> > Yes.
>
> Wouldn't the compiler try to catch errors like this at compile time?
Simple
> data flow.  Local variables cannot outlive the function, and cannot be
used
> in a return statement, even indirectly.  Their values can be returned, however.  I guess you have to allow passing local variables to other functions as parameters..

I agree it should be a compiler warning. I also agree that it should have the behaviour that it does, rather than trying to do something smart like an implicit .dup. (I'm not suggesting you were suggesting that, of course, just blithering on. ;)

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bmr28m$plk$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:bmqv3c$lok$4@digitaldaemon.com...
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bmqqet$dgb$1@digitaldaemon.com...
> > > char[] fn()
> > > {
> > >   char ar[21];
> > >   int    cch = sprintf(ar, "%d", 101);
> > >
> > >   return ar[0 .. cch];
> > > }
> > >
> > > Does this return a slice into something that (no longer) exists on the
> > > stack,
> >
> > Yes.
>
> Wouldn't the compiler try to catch errors like this at compile time?
Simple
> data flow.  Local variables cannot outlive the function, and cannot be
used
> in a return statement, even indirectly.  Their values can be returned, however.  I guess you have to allow passing local variables to other functions as parameters..

It is illegal to do that in D, and whether the compiler issues an error or not is a quality of implementation issue. The trouble is, for simple cases the compiler can detect it. For complex cases, it cannot, therefore the spec can't require that it diagnose the error.

Also, it is an error, not a warning <g>.

The exact same problem exists in C and C++.

Ok, so long as it's officially an error, the good compilers can reject such code.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bms3hr$23v2$3@digitaldaemon.com...
> > Wouldn't the compiler try to catch errors like this at compile time?
> Simple
> > data flow.  Local variables cannot outlive the function, and cannot be
> used
> > in a return statement, even indirectly.  Their values can be returned, however.  I guess you have to allow passing local variables to other functions as parameters..
>
> It is illegal to do that in D, and whether the compiler issues an error or not is a quality of implementation issue. The trouble is, for simple cases the compiler can detect it. For complex cases, it cannot, therefore the
spec
> can't require that it diagnose the error.
>
> Also, it is an error, not a warning <g>.
>
> The exact same problem exists in C and C++.