On Friday, 25 October 2013 at 16:31:54 UTC, Max Samukha wrote:
If you define the string type to include null, then null
should be either identical to empty in *all cases* or
distinct from that in all cases.
AFAIK, that's how equality operator works, use it and you will
get the desired
I find that have repeated myself a lot in each section/reply below, I am
not sure whether you'd prefer I just reply with those points once, or
inline, I chose inline so as it make it clear I was not ignoring your
points, and to make it clear which of my arguments apply to which point...
:)
On 10/25/2013 11:02 PM, Shammah Chancellor wrote:
... null == 0 ... in C, C++, and D,
Check again.
On Monday, 21 October 2013 at 10:33:01 UTC, Regan Heath wrote:
null strings are no different to null class references, they're
not a special case.
True. That's an implementation detail which has no meaning for
business logic. When implementation deviates from business logic,
one ends up
On Friday, 25 October 2013 at 11:41:38 UTC, Kagamin wrote:
That's an implementation detail which has no meaning for
business logic.
I've no real truck in this, but I do find it pretty bizarre to
see _anyone_ using business logic as justification for anything
here when D's own documentation
On Friday, 25 October 2013 at 11:41:38 UTC, Kagamin wrote:
On Monday, 21 October 2013 at 10:33:01 UTC, Regan Heath wrote:
null strings are no different to null class references,
they're not a special case.
True. That's an implementation detail which has no meaning for
business logic. When
On Friday, 25 October 2013 at 12:35:44 UTC, Wyatt wrote:
On Friday, 25 October 2013 at 11:41:38 UTC, Kagamin wrote:
That's an implementation detail which has no meaning for
business logic.
I've no real truck in this, but I do find it pretty bizarre to
see _anyone_ using business logic as
*fix* I mean a product.
On Friday, 25 October 2013 at 16:31:54 UTC, Max Samukha wrote:
D chose to fuse null and empty together in an inconsistent
manner, which is a mistake.
Slices are reasonably consistent and perfectly working with
reasonable code, so I see no merit in fixing them, but you can
try, why not.
On 2013-10-18 17:32:58 +, Jonathan M Davis said:
On Friday, October 18, 2013 09:55:46 Andrei Alexandrescu wrote:
On 10/18/13 9:26 AM, Max Samukha wrote:
*That's* bad API design. readln should be symmetrical to writeln, not
write. And about preserving the exact representation of new lines,
On 2013-10-25 11:41:36 +, Kagamin said:
Oracle makes no distinction between null and empty string. For a reason?
A database is an implementation detail of a data storage, it doesn't
implement business logic, it only provides features, which can be used
with more or less success to
As the OP of this thread I want to say that I think nullable is
the solution http://dlang.org/phobos/std_typecons.html but I
dislike how I cant pass 5 or null to a parameter that is
nullable!int, nullable!string
On Mon, 21 Oct 2013 17:34:51 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Mon, Oct 21, 2013 at 04:41:23PM +0100, Regan Heath wrote:
On Mon, 21 Oct 2013 15:01:04 +0100, H. S. Teoh
hst...@quickfur.ath.cx wrote:
On Mon, Oct 21, 2013 at 11:53:44AM +0100, Regan Heath wrote:
[...]
I agree
On Mon, 21 Oct 2013 17:49:43 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Mon, Oct 21, 2013 at 04:47:05PM +0100, Regan Heath wrote:
On Mon, 21 Oct 2013 15:02:35 +0100, H. S. Teoh
hst...@quickfur.ath.cx wrote:
On Mon, Oct 21, 2013 at 10:40:14AM +0100, Regan Heath wrote:
On Fri, 18 Oct
On Fri, 18 Oct 2013 17:36:28 +0100, Dicebot pub...@dicebot.lv wrote:
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu wrote:
That's bad API design, pure and simple. The function should e.g. return
the string including the line terminator, and only return an empty (or
null)
On Sat, 19 Oct 2013 10:56:02 +0100, Kagamin s...@here.lot wrote:
On Friday, 18 October 2013 at 10:44:11 UTC, Regan Heath wrote:
This comes up time and again. The use of, and ability to distinguish
empty from null is very useful. Yes, you run the risk of things like
null pointer exceptions
On Fri, 18 Oct 2013 16:43:23 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/18/13 3:44 AM, Regan Heath wrote:
On Fri, 18 Oct 2013 00:32:46 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
On Thursday, 17
On Fri, 18 Oct 2013 17:55:46 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/18/13 9:26 AM, Max Samukha wrote:
*That's* bad API design. readln should be symmetrical to writeln, not
write. And about preserving the exact representation of new lines,
readln/writeln
On Fri, 18 Oct 2013 18:38:12 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Fri, Oct 18, 2013 at 01:32:58PM -0400, Jonathan M Davis wrote:
On Friday, October 18, 2013 09:55:46 Andrei Alexandrescu wrote:
On 10/18/13 9:26 AM, Max Samukha wrote:
*That's* bad API design. readln should be
On Fri, 18 Oct 2013 20:58:07 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Fri, Oct 18, 2013 at 02:04:41PM -0400, Jonathan M Davis wrote:
On Friday, October 18, 2013 10:38:12 H. S. Teoh wrote:
[...]
IMO, distinguishing between null and empty arrays is bad
abstraction. I agree with
On Fri, 18 Oct 2013 21:09:35 +0100, Blake Anderton rbander...@gmail.com
wrote:
I agree a null value and empty array are separate concepts, but from my
very anecdotal/non rigorous point of view I really appreciate D's
ability to treat them as equivalent.
My day job mostly involves C# and
On Mon, 21 Oct 2013 11:58:07 +0100, Regan Heath re...@netmail.co.nz
wrote:
On Fri, 18 Oct 2013 20:58:07 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Fri, Oct 18, 2013 at 02:04:41PM -0400, Jonathan M Davis wrote:
On Friday, October 18, 2013 10:38:12 H. S. Teoh wrote:
[...]
IMO,
On Monday, October 21, 2013 11:58:07 Regan Heath wrote:
If what you say is true then slices would and could never be null... If
that were the case I would stop complaining and simply box them with
Nullable when I wanted a reference type. But, D's strings/slices are some
kind of mutant half
On Monday, 21 October 2013 at 09:40:13 UTC, Regan Heath wrote:
I disagree. Exceptions should never be used for flow control
so the rule is to throw on exceptional occurrences ONLY not on
something that you will ALWAYS eventually happen.
For such function it is exceptional situation. For
On Mon, Oct 21, 2013 at 11:53:44AM +0100, Regan Heath wrote:
On Fri, 18 Oct 2013 18:38:12 +0100, H. S. Teoh
hst...@quickfur.ath.cx wrote:
[...]
Conceptually speaking, an array is a sequence of values of
non-negative length. An array with non-zero length contains at least
one element, and is
On Mon, Oct 21, 2013 at 10:40:14AM +0100, Regan Heath wrote:
On Fri, 18 Oct 2013 17:36:28 +0100, Dicebot pub...@dicebot.lv wrote:
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu wrote:
That's bad API design, pure and simple. The function should e.g.
return the string
On Mon, 21 Oct 2013 15:01:04 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Mon, Oct 21, 2013 at 11:53:44AM +0100, Regan Heath wrote:
On Fri, 18 Oct 2013 18:38:12 +0100, H. S. Teoh
hst...@quickfur.ath.cx wrote:
[...]
Conceptually speaking, an array is a sequence of values of
On Mon, 21 Oct 2013 12:54:56 +0100, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Monday, October 21, 2013 11:58:07 Regan Heath wrote:
If what you say is true then slices would and could never be null... If
that were the case I would stop complaining and simply box them with
Nullable when I
On Mon, 21 Oct 2013 15:02:35 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Mon, Oct 21, 2013 at 10:40:14AM +0100, Regan Heath wrote:
On Fri, 18 Oct 2013 17:36:28 +0100, Dicebot pub...@dicebot.lv wrote:
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu wrote:
That's bad
On Mon, Oct 21, 2013 at 04:41:23PM +0100, Regan Heath wrote:
On Mon, 21 Oct 2013 15:01:04 +0100, H. S. Teoh
hst...@quickfur.ath.cx wrote:
On Mon, Oct 21, 2013 at 11:53:44AM +0100, Regan Heath wrote:
[...]
I agree you cannot logically have an existing array that is somehow
a null array and
On Mon, Oct 21, 2013 at 04:47:05PM +0100, Regan Heath wrote:
On Mon, 21 Oct 2013 15:02:35 +0100, H. S. Teoh
hst...@quickfur.ath.cx wrote:
On Mon, Oct 21, 2013 at 10:40:14AM +0100, Regan Heath wrote:
On Fri, 18 Oct 2013 17:36:28 +0100, Dicebot pub...@dicebot.lv wrote:
On Friday, 18 October
On Friday, 18 October 2013 at 10:44:11 UTC, Regan Heath wrote:
This comes up time and again. The use of, and ability to
distinguish empty from null is very useful. Yes, you run the
risk of things like null pointer exceptions etc, but we have
that risk now without the reward of being able to
Jesse Phillips:
Why do we even allow checking against null, can't do it
with int or bool. (ok, I know, breaks code).
Sometimes breaking code is acceptable.
Bye,
bearophile
On Friday, 18 October 2013 at 17:59:17 UTC, Max Samukha wrote:
On Friday, 18 October 2013 at 16:55:19 UTC, Andrei Alexandrescu
wrote:
Fair point. I just gave one possible alternative out of many.
Thing is, relying on client code to distinguish subtleties
between empty and null strings is
On Saturday, 19 October 2013 at 12:04:43 UTC, Kagamin wrote:
On Friday, 18 October 2013 at 17:59:17 UTC, Max Samukha wrote:
On Friday, 18 October 2013 at 16:55:19 UTC, Andrei
Alexandrescu wrote:
Fair point. I just gave one possible alternative out of many.
Thing is, relying on client code to
On Fri, 18 Oct 2013 00:32:46 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost
wrote:
is null still treats [] as null.
blah, you're right. It will at least distinguish
On 10/18/2013 12:50 AM, ProgrammingGhost wrote:
How do I find out if null was passed in? As you can guess I wasn't happy
with the current behavior.
...
http://forum.dlang.org/thread/rkdzdxygpflpnaznx...@forum.dlang.org?page=5
On 10/18/13 3:44 AM, Regan Heath wrote:
On Fri, 18 Oct 2013 00:32:46 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost
wrote:
is null still treats [] as null.
blah,
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu
wrote:
On 10/18/13 3:44 AM, Regan Heath wrote:
On Fri, 18 Oct 2013 00:32:46 +0100, H. S. Teoh
hst...@quickfur.ath.cx
wrote:
On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 23:12:03
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu
wrote:
That's bad API design, pure and simple. The function should
e.g. return the string including the line terminator, and only
return an empty (or null) string upon EOF.
I'd say it should throw upon EOF as it is pretty
On 10/18/13 9:26 AM, Max Samukha wrote:
*That's* bad API design. readln should be symmetrical to writeln, not
write. And about preserving the exact representation of new lines,
readln/writeln shouldn't preserve that, pure and simple.
Fair point. I just gave one possible alternative out of
On Fri, Oct 18, 2013 at 06:26:05PM +0200, Max Samukha wrote:
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu
wrote:
On 10/18/13 3:44 AM, Regan Heath wrote:
[...]
Take this simple design:
string readline();
This function would like to be able to:
- return null for EOF
On Friday, October 18, 2013 09:55:46 Andrei Alexandrescu wrote:
On 10/18/13 9:26 AM, Max Samukha wrote:
*That's* bad API design. readln should be symmetrical to writeln, not
write. And about preserving the exact representation of new lines,
readln/writeln shouldn't preserve that, pure and
On Fri, Oct 18, 2013 at 01:32:58PM -0400, Jonathan M Davis wrote:
On Friday, October 18, 2013 09:55:46 Andrei Alexandrescu wrote:
On 10/18/13 9:26 AM, Max Samukha wrote:
*That's* bad API design. readln should be symmetrical to writeln,
not write. And about preserving the exact
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu
wrote:
This comes up time and again. The use of, and ability to
distinguish
empty from null is very useful.
I disagree.
That what if does by default.
On Friday, 18 October 2013 at 16:55:19 UTC, Andrei Alexandrescu
wrote:
Fair point. I just gave one possible alternative out of many.
Thing is, relying on client code to distinguish subtleties
between empty and null strings is fraught with dangers.
Andrei
I agree. Thinking about your
On Friday, October 18, 2013 10:38:12 H. S. Teoh wrote:
On Fri, Oct 18, 2013 at 01:32:58PM -0400, Jonathan M Davis wrote:
On Friday, October 18, 2013 09:55:46 Andrei Alexandrescu wrote:
On 10/18/13 9:26 AM, Max Samukha wrote:
*That's* bad API design. readln should be symmetrical to
On Fri, Oct 18, 2013 at 02:04:41PM -0400, Jonathan M Davis wrote:
On Friday, October 18, 2013 10:38:12 H. S. Teoh wrote:
[...]
IMO, distinguishing between null and empty arrays is bad
abstraction. I agree with D's conflation of null with empty,
actually. Conceptually speaking, an array is a
On Friday, 18 October 2013 at 19:59:26 UTC, H. S. Teoh wrote:
...because it eliminates an unnecessary distinction between an
empty sequence and a non-existent sequence (which then leads to
similar issues one encounters with null pointers).
That just seems silly. Surely we all recognize that
I agree a null value and empty array are separate concepts, but
from my very anecdotal/non rigorous point of view I really
appreciate D's ability to treat them as equivalent.
My day job mostly involves C# and array code almost always
follows the pattern if(arr == null || arr.Length == 0) ...
On 10/18/2013 09:58 PM, H. S. Teoh wrote:
To me, these are just implementation details. Conceptually speaking, D
arrays are actually slices, so that gives them reference semantics.
Being slices, they refer to zero or more elements, so either their
length is zero, or not. There is no concept of
On 10/18/2013 10:09 PM, Blake Anderton wrote:
I agree a null value and empty array are separate concepts, but from my
very anecdotal/non rigorous point of view I really appreciate D's
ability to treat them as equivalent.
My day job mostly involves C# and array code almost always follows the
On Friday, 18 October 2013 at 20:15:31 UTC, Timon Gehr wrote:
(This will work either way.)
Speaking of that, it's really annoying to have to import
std.array just to use range primitives with slices. Would these
be better in druntime, or is that a bad idea?
On Friday, 18 October 2013 at 20:09:37 UTC, Blake Anderton wrote:
I agree a null value and empty array are separate concepts, but
from my very anecdotal/non rigorous point of view I really
appreciate D's ability to treat them as equivalent.
My day job mostly involves C# and array code almost
On Friday, 18 October 2013 at 20:09:37 UTC, Blake Anderton wrote:
I agree a null value and empty array are separate concepts […]
Yes, null values are a different concept, and slices being value
types, there isn't really one for them. I'm torn on whether
allowing conversion of arrays to
On Friday, 18 October 2013 at 20:32:48 UTC, ProgrammingGhost
wrote:
Really? I NEVER write that pattern. I may check if an array is
null or don't because the function shouldnt be receiving nulls
(maybe its bad but idc). I just write linq and never bother to
see if something is empty
Yeah,
On Fri, Oct 18, 2013 at 10:04:52PM +0200, Meta wrote:
On Friday, 18 October 2013 at 19:59:26 UTC, H. S. Teoh wrote:
...because it eliminates an unnecessary distinction between an
empty sequence and a non-existent sequence (which then leads to
similar issues one encounters with null pointers).
On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
Yes, but if you declare a variable to contain a set, then by
definition there is *something*, even if it's an empty set.
Exactly. There is still *something*, even though the set is
empty. That is, the set itself.
For there to be
On Sat, Oct 19, 2013 at 12:04:47AM +0200, Meta wrote:
On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
Yes, but if you declare a variable to contain a set, then by
definition there is *something*, even if it's an empty set.
Exactly. There is still *something*, even though the
On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
On Fri, Oct 18, 2013 at 10:04:52PM +0200, Meta wrote:
On Friday, 18 October 2013 at 19:59:26 UTC, H. S. Teoh wrote:
...because it eliminates an unnecessary distinction between an
empty sequence and a non-existent sequence (which then
On Sat, Oct 19, 2013 at 12:45:02AM +0200, ProgrammingGhost wrote:
On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
On Fri, Oct 18, 2013 at 10:04:52PM +0200, Meta wrote:
On Friday, 18 October 2013 at 19:59:26 UTC, H. S. Teoh wrote:
...because it eliminates an unnecessary
You could use T[]* and pass a null pointer as default?
Yet this answer wasn't on the first page.
I see I can't write fn([1,2]) anymore so I'm unsure how this
solution compares to using Nullable (I can't write fn([1,2]) with
nullable either).
On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
Yes, but if you declare a variable to contain a set, then by
definition
there is *something*, even if it's an empty set. For there to be
nothing, there shouldn't even be a variable in the first place.
The fact
that the variable
How do I find out if null was passed in? As you can guess I
wasn't happy with the current behavior.
Code:
import std.stdio;
void main() {
fn([1,2]);
fn(null);
fn([]);
}
void fn(int[] v) {
Sorry I misspoke. I meant to say empty array or not null passed
in. The 3rd call to fn is what I didn't like.
On Thursday, 17 October 2013 at 23:00:12 UTC, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost
wrote:
How do I find out if null was passed in?
try if(v is null) { use default }
if all you care about is if there's contents, I like to use
if(v.length) {}
On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost
wrote:
How do I find out if null was passed in?
try if(v is null) { use default }
if all you care about is if there's contents, I like to use
if(v.length) {}
On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost
wrote:
How do I find out if null was passed in? As you can guess I
wasn't happy with the current behavior.
Code:
import std.stdio;
void main() {
fn([1,2]);
fn(null);
On Thursday, 17 October 2013 at 23:00:12 UTC, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost
wrote:
How do I find out if null was passed in?
try if(v is null) { use default }
if all you care about is if there's contents, I like to use
if(v.length) {}
On Thursday, 17 October 2013 at 23:14:51 UTC, anonymous wrote:
On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost
wrote:
How do I find out if null was passed in? As you can guess I
wasn't happy with the current behavior.
Code:
import std.stdio;
void main() {
On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost
wrote:
is null still treats [] as null.
blah, you're right. It will at least distinguish it from an empty
slice though (like arr[$..$]). I don't think there's any way to
tell [] from null except typeof(null) at all. At runtime
On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost
wrote:
is null still treats [] as null.
blah, you're right. It will at least distinguish it from an empty
slice though (like arr[$..$]). I don't think there's any
72 matches
Mail list logo
