On 03/04/2011 09:15 AM, Lars T. Kyllingstad wrote:
On Fri, 04 Mar 2011 13:53:33 +1030, Graham St Jack wrote:
On 04/03/11 12:34, Bekenn wrote:
On 3/3/11 3:30 PM, Graham St Jack wrote:
My first instinct would be to use non-templated functions that take
const
char[].
Please don't ever restrict encodings like that. As much as possible,
libraries should seek to be encoding agnostic (though I'm all for
const-qualifying parameters). This is one area where I feel the
standard library severely lacks at present.
As a Windows developer, I prefer to use wchar strings by default and
use only the W versions of the Windows API functions, because the A
versions severely limit functionality. Only the W versions have full
support for Unicode; the A versions are entirely dependent on the
current (8-bit) code page. This means no support for UNC paths or
paths longer than 260 characters, and also means that international
characters commonly end up completely garbled. Good practice in
Windows is to consider the A versions deprecated and avoid them like
the plague.
Ok, I don't mind supporting wchar and dchar in addition to char,
especially if Windows insists on using them.
My main issue here is with the constness of the parameters. I think the
correct parameter to pass is const C[]. This has the advantages of: *
Accepting both mutable and immutable data. * Declares that the function
won't mutate the data. * Declares that the function doesn't expect the
data to be immutable.
The problem is that the functions return slices of their input argument,
which means that the constancy of the input argument gets transferred to
the return value. Here's an example to illustrate:
C[] first(C)(const C[] s) { return s[0 .. 1]; }
char[] a = "hello".dup;
auto b = first(a);
Try to compile this, and you get the error message
Error: cannot implicitly convert expression (s[0u..1u])
of type const(char[]) to char[]
IIUC, this means const should never be used on input parameters. Instead of
meaning what the func will (not) do with its param(s), it imposes undue
requirements on the outside world. Or do I miss something? From my point of
view, qualifiers inside a function's interface should only describe the
function behaviour.
Denis
--
_________________
vita es estrany
spir.wikidot.com
