--- Comment #2 from 2012-06-12 10:55:45 PDT ---
(In reply to comment #1)
> This behaviour is intentional. Pointer operations are strictly checked in 
> It's the same as doing 
> int n = 0;
> char c = ""[n];
> which generates an array bounds error at runtime.

I think that would be stretching it too far. It is more like:

auto s = ['\0'];
auto q = s[0..0];
char c = *q.ptr;

Which works fine at runtime and during CTFE.

> Is the terminating null character still in the spec? A long time ago it was in
> there, but now I can only find two references to it in the current spec (in
> 'arrays' and in 'interfacing to C'), and they both relate to printf. 
> The most detailed is in 'interface to C', which states:
> "string literals, when they are not part of an initializer to a larger data
> structure, have a '\0' character helpfully stored after the end of them."
> which is pretty weird. These funky semantics would be difficult to implement 
> in

I guess this is from D1 times, when string literals were static arrays, and
doesn't apply anymore.

> and I doubt they are desirable. Here's an example:
> const(char)[] foo(char[] s) { return "abc" ~ s; }
> immutable bar = foo("xyz"); // becomes a string literal when it leaves CTFE

Well, this is not specified afaics.

> bool baz()
> {
>     immutable bar2 = foo("xyz"); // local variable, so isn't a string literal.
>     return true;
> }
> static assert(baz());
> ---> bar is zero-terminated, bar2 is not, even though they had the same
> assignment. When does this magical trailing zero get added?

This is exactly the behavior that is observed at runtime. If it is undesirable,
then that is a distinct issue that should be investigated.

It would certainly be desirable to have consistent behavior at compile time and
at runtime, but this is not a top-priority issue.

> I think you could reasonably interpret the spec as meaning that a trailing 
> zero
> is added to the end of string literals by the linker, not by the compiler. 
> It's
> only in CTFE that you can tell the difference.

In this case, the spec should definitely be fixed.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to