string and char[] in Phobos

[Puming via Digitalmars-d-learn]

On Friday, 18 March 2016 at 20:06:27 UTC, Jonathan M Davis wrote:
>
> When a function accepts const(char)[] than it can accept char[],
> const(char)[], const(char[]), immutable(char)[], and 
> immutable(char[]),
> which, whereas if it accepts string, then all it accepts are
> immutable(char)[] and immutable(char[]). So, it's more
So I need to use const(char)[] in my function definitions instead 
of in char[]?
> restrictive, but if
> you need to return a slice of the array you passed in, if your 
> function
> accepts const rather than mutable or immutable, then the slice 
> has to be
> const, and you've lost the type information, which is why inout 
> exists -
Well, I never got inout until now, thanks!
> [...]
> I don't know what you're using in Phobos that takes string and 
> returns char[]. That implies an allocation, and if the function 
> is pure, char[] may have been selected, because it could be 
> implicitly converted to string thanks to the fact that the 
> compiler could prove that the char[] being returned had to have 
> been allocated in the function and that there could be no other 
> references to that array. But without knowing exactly which 
> functions you're talking about, I can't really say. In general 
> though, the solution that we've gone with is to templatize 
> functions that operate on strings, and a function that's taking 
> a string explicitly is most likely storing it, in which case, 
> it needs an explicit type, and using an immutable value ensures 
> that it doesn't change later.

I just got this feeling from using functions in the std.file 
module, like dirEntries and File constructor itself. After 
reading your explaination, it makes sense now. And with a second 
look up, most functions there ARE alread templatized. Thanks for 
your clarification.
>
> On a side note, I'd strongly argue against using "in" on 
> function arguments that aren't delegates. in is equivalent to 
> const scope, and scope currently does nothing for any types 
> other than delegates - but it might later, in which case, you 
> could be forced to change your code, depending on the exact 
> semantics of scope for non-delegates. But it does _nothing_ now 
> with non-delegate types regardless, so it's a meaningless 
> attribute that might change meaning later, which makes using it 
> a very bad idea IMHO. Just use const if you want const and 
> leave scope for delegates. I'd actually love to see in 
> deprecated, because it adds no value to the language (since 
> it's equivalent to const scope, which you can use explicitly), 
> and it hides the fact that scope is used.

Well, this is too complicated level for me now. I'll get to that 
later when I learn more with the language.

My take away from your post:

- when the function is pure for the stringlike, use 
'const(char)[]' or 'inout(char)[]' when neccessary.
- when the argument is stored in the function, use string.
- manually convert stringlike objects to string with to!string 
when calling those functions.

are those above correct?

>
> - Jonathan M Davis