Just saw that my first example was wrong, it should read
1 void main ()
2 {
3 import std.uri;
4 string a = "";
5 assert (a);
6 auto s = a.decodeComponent;
7 assert (s);
8 }
The non-nullity was not preserved. Only the second assert fails.
On Saturday, 8 July 2017 at 18:39:47 UTC, ag0aep6g wrote:
On 07/08/2017 07:16 PM, kdevel wrote:
null is one specific array. It happens to be empty, but that
doesn't really matter. `foo is null` compares with the null
array. It doesn't check for emptiness. Conversion to bool also
compares with null. The concept of emptiness is unrelated.
But why? What is the intended use of converting a string (or any
other dynamic array) to bool?
In Issue 17623 Vladimir pointed out, that in the case of strings
there may be a need to store an empty D-string which also is a
NUL-terminated C-String. It would be sufficient if the ptr-Value
would convert for checking if there is a valid part of memory
containing the NUL byte.
Moreover everything I've written about strings is also valid for
e.g. dynamic arrays of doubles. Here there are also two different
kinds of empty arrays which compare equal but are not identical.
I see no purpose for that.
I wonder if this distinction is meaningful and---if not---why
it is
exposed to the application programmer so prominently.
"Prominently"? It only shows up when you convert to bool.
The conversion to bool (in a bool context) is part of the
interface of the type. The interface of a type *is* prominently
exposed.
You only get surprised if you expect that to check for
emptiness (or something else entirely).
As mentioned I was surprised, that the non-nullity did not pass
thru decodeComponent.
The spec isn't very clear there. What does "the same array
elements" mean for empty arrays?
Mathematically that's easily answered:
https://en.wikipedia.org/wiki/Universal_quantification#The_empty_set
(mkdir)
Using DMD v2.073.2 the first expression terminates the
programm with a
segmentation fault. With 2.074.1 the program prints
: Bad address
: No such file or directory
I find that a bit confusing.
That looks like a bug/oddity in mkdir. null is as valid a
string as "". It shouldn't give a worse exception message.
But the message for `""` isn't exactly good, either. Of course
the directory doesn't exist, yet; I'm trying to create it!
I would expect the same error message (ENOENT) in both cases. The
EFAULT in
the first case occurs if you invoke POSIX mkdir with NULL as
first argument.
