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
