digitalmars.D.learn - What other than a pointer can be converted implicitly to const(char)*?
- Shriramana Sharma (7/7) Dec 21 2015 https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#...
- anonymous (11/16) Dec 21 2015 A struct/class with an `alias this` to a `const(char)*`:
- Steven Schveighoffer (5/24) Dec 21 2015 This seems like an incorrect feature then. Why wouldn't I want S to be
- anonymous (11/14) Dec 21 2015 To my understanding, `alias this` means "is implicitly convertible to
- Steven Schveighoffer (10/24) Dec 21 2015 I'm not saying that isPointer should return true, I'm saying that it
https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L878 The `static if` condition here says if something is a pointer and if it is implicitly convertible to const(char)*. The isPointer! part seems superfluous. Is there something that is not a pointer yet implicitly convertible to const(char)*? --
Dec 21 2015
On 21.12.2015 17:02, Shriramana Sharma wrote:https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L878 The `static if` condition here says if something is a pointer and if it is implicitly convertible to const(char)*. The isPointer! part seems superfluous. Is there something that is not a pointer yet implicitly convertible to const(char)*?A struct/class with an `alias this` to a `const(char)*`: ---- import std.traits: isPointer; struct S { const(char)* ptr; alias ptr this; } static assert(!isPointer!S && is(S : const(char)*)); /* passes */ ----
Dec 21 2015
On 12/21/15 12:03 PM, anonymous wrote:On 21.12.2015 17:02, Shriramana Sharma wrote:This seems like an incorrect feature then. Why wouldn't I want S to be treated like any other const(char)*? Seems like it's explicitly saying "treat this like a const(char)*" -Stevehttps://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L878 The `static if` condition here says if something is a pointer and if it is implicitly convertible to const(char)*. The isPointer! part seems superfluous. Is there something that is not a pointer yet implicitly convertible to const(char)*?A struct/class with an `alias this` to a `const(char)*`: ---- import std.traits: isPointer; struct S { const(char)* ptr; alias ptr this; } static assert(!isPointer!S && is(S : const(char)*)); /* passes */ ----
Dec 21 2015
On 21.12.2015 21:20, Steven Schveighoffer wrote:This seems like an incorrect feature then. Why wouldn't I want S to be treated like any other const(char)*? Seems like it's explicitly saying "treat this like a const(char)*"To my understanding, `alias this` means "is implicitly convertible to X", and not "is the same thing as X". That is, `is(S == const(char)*)` is false, but `is(S : const(char)*)` is true. It makes sense to me that isPointer behaves like the `==` variant. And for sure, the `alias this` doesn't make S interchangeable with a pointer. S may have a different size, the pointer may not be at a zero offset in S, etc. For the phobos code in question it comes down to what's less surprising, I guess. Having such an `alias this` resolved before stringification, or not. I'm not sure.
Dec 21 2015
On 12/21/15 3:47 PM, anonymous wrote:On 21.12.2015 21:20, Steven Schveighoffer wrote:I'm not saying that isPointer should return true, I'm saying that it shouldn't be used here.This seems like an incorrect feature then. Why wouldn't I want S to be treated like any other const(char)*? Seems like it's explicitly saying "treat this like a const(char)*"To my understanding, `alias this` means "is implicitly convertible to X", and not "is the same thing as X". That is, `is(S == const(char)*)` is false, but `is(S : const(char)*)` is true. It makes sense to me that isPointer behaves like the `==` variant. And for sure, the `alias this` doesn't make S interchangeable with a pointer. S may have a different size, the pointer may not be at a zero offset in S, etc.For the phobos code in question it comes down to what's less surprising, I guess. Having such an `alias this` resolved before stringification, or not. I'm not sure.I think the issue here is the way the code determines it should use std.format. My preference is: 1. if the struct defines toString, then use std.format which will call that. 2. else if the struct aliases itself to some other type handled here, use that branch 3. else, use std.format anyway, and whatever happens happens. -Steve
Dec 21 2015