Bug 10724 – Allow slice of string literal to convert to const(char)*

The following code is perfectly safe because the slice happens at compile time, but the conversion is not allowed. void main() { const(char)* s = "abc"[0..$-1]; }

Implicit conversions introduce a bit of dangers in a language. They should be minimized. Instead of this: const(char)* s = "abc"[0..$-1]; What about this? const(char)* s = "abc"[0..$-1].ptr;

(In reply to comment #2) > Implicit conversions introduce a bit of dangers in a language. They should be > minimized. > > Instead of this: > const(char)* s = "abc"[0..$-1]; > > What about this? > const(char)* s = "abc"[0..$-1].ptr; The conversion is only safe because the string literal is null-terminated. Explicitly adding .ptr bypasses that, making it unsafe to rely on this. Currently `"abc"[0..$-1]` gets const-folded to (essentially) `cast(string)"ab"`, and not for any reason I can see. It should be just plain "ab", which can convert to a const cstring. The only downside I can see is potential confusion that the above works, but this doesn't: string str = "abc"[0..$-1]; const(char)* s = str; But this is already present with plain string literals, as well as concatenation and probably others.

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a878588c71ea51e2365cd595dc38413700cc3d8a Fix Issue 10724 - Allow slice of string literal to convert to const(char)* https://github.com/D-Programming-Language/dmd/commit/e230276ee0703a3cdf92e16e1b9f388be44e9c54 Merge pull request #2392 from yebblies/issue10724 [DDMD] Fix Issue 10724 - Allow slice of string literal to convert to const(char)*

Just to clarify: const(char)* a = "abc"; const(char)* b = "abc"[0..$-1]; Do a and b end up pointing to different memory addresses?

(In reply to comment #5) > Just to clarify: > > const(char)* a = "abc"; > const(char)* b = "abc"[0..$-1]; > > Do a and b end up pointing to different memory addresses? Yes.

The following used not to work in v2.063.2: const a = "a"; const b = a ~ "b"; const(char)* output = b; $ Error: cannot implicitly convert expression ("ab") of type const(immutable(char)[]) to const(char)* Although this worked: const b = "a" ~ "b"; const(char)* output = b; Now both work. I assume it was the fix for this issue (10724) that also fixed this? I say fixed because at first glance the old behavior seems wrong, but it seems such a basic statement that I wonder why this wasn't spotted before, or if I'm making a mistake. So please confirm this change in behavior was also desirable.

(In reply to comment #7) > The following used not to work in v2.063.2: > > const a = "a"; > const b = a ~ "b"; > const(char)* output = b; > > $ Error: cannot implicitly convert expression ("ab") of type > const(immutable(char)[]) to const(char)* > > Although this worked: > > const b = "a" ~ "b"; > const(char)* output = b; > > Now both work. I assume it was the fix for this issue (10724) that also fixed > this? I say fixed because at first glance the old behavior seems wrong, but it > seems such a basic statement that I wonder why this wasn't spotted before, or > if I'm making a mistake. So please confirm this change in behavior was also > desirable. All this patch changed was the 'committing' behavior of SliceExp constfolding. Without a slice anywhere in there it doesn't look like this patch is the cause. The code does appear to be valid as 'a' and 'b' are const variables with initializers known at compile time, so the const-folder can determine that 'output' is assigned a string literal and allow the conversion. I would expect replacing any of them with a run-time determined value will prevent the conversion.