October 30, 2017
On Monday, 30 October 2017 at 15:04:32 UTC, Steven Schveighoffer wrote:
>> https://issues.dlang.org/show_bug.cgi?id=13489
...
> I'm in the camp that nan should be evaluated as false. I don't think I like the idea that !nan is also false, because this makes !!nan true!
>

The problem of converting NaN to binary is that NaN introduces a ternary logic. There is no way to convert the ternary value to binary without loss. If we want to be consistent we have to convert it to Nullable!bool, but not to bool. So, to introduce Elvis operator for floats in language and to stay consistent it needs also Nullable/Not-Nullable as part of language type system, IMHO.

October 30, 2017
On Monday, 30 October 2017 at 19:51:30 UTC, Jonathan M Davis wrote:
> Yeah. Honestly, I stay away from if(x) in general if x isn't a bool.

That's the best option, even for ints. The proper way to cast to bool is to be explicit. A lot of the shorthand in C probably had to do with early CRTs not being able to display a lot of text. At this day and age readability (easy to scan quickly) should be more important than terseness.

> The fact that NaN == NaN is false and yet cast(bool)NaN is true though is just attrocious though. We aren't source compatible with C like C++ is, and yet we're still bound by it in so many small, stupid ways - largely because of the risk of ported code going badly.

I think some of the float semantics aren't in the standard, but in IEEE754. But many languages have picked up many of C's not-so-great design characteristics. I think largely because people who write their own compilers tend to program in C… so more cultural than rational.

October 30, 2017
On Mon, Oct 30, 2017 at 01:51:30PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Monday, October 30, 2017 11:04:32 Steven Schveighoffer via Digitalmars-d wrote:
[...]
> > TBH, I don't think I ever considered doing if(floatingpointvalue) to be a good idea in C or D. I generally stay away from float, and especially comparing to 0 directly.
> 
> Yeah. Honestly, I stay away from if(x) in general if x isn't a bool. I
> might occasionally do it for a pointer, but it's not like floating
> point types are the only ones that act badly with cast(bool) (e.g.
> dynamic arrays). It all works just fine if you understand what each of
> the types do with cast(bool), but it's just clearer if you make the
> check it explicit.

+1 for writing it explicitly.  It reminds me of C code along these lines:

	if (some_function(x)) {
		cleanup();
		return ERROR;
	}
	if (some_other_function(y)) {
		return SUCCESS;
	}

Typical result of the widespread C convention of returning int that can mean ... basically anything.  Some functions return 0 to mean error, some return 0 to mean success, and of course, on the caller's side you assume clairvoyance on the part of the would-be reader of your code to know what was intended.

Which leads to fun (or insanity) like this:

	int f(char *s, int x) {
		return strcmp(s, "verbose") && !printf("The result is ")
			|| x && !printf("success ") || isalnum(x) &&
			!printf("unknown ") || printf("(%d)", x) &&
			printf("\n");
	}


Back in D land, I was so happy way back when, when dmd began rejecting this code:

	S* sp;
	while ((sp = getS()) && someCondition) { ... }

and I had to write this instead:

	S* sp;
	while ((sp = getS()) !is null && someCondition) { ... }

Added a whole new level of readability to my code.

Nowadays, I don't even like using implicit conversions to bool anymore. Intent is much better conveyed with an explicit comparison to 0 or 1 or whatever.  Saving a few keystrokes simply isn't worth the amount of time and mental fatigue incurred when you need to debug something that's caused by wrong interpretation of return values.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!
October 30, 2017
On Monday, October 30, 2017 21:47:50 Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Monday, 30 October 2017 at 19:51:30 UTC, Jonathan M Davis
> > The fact that NaN == NaN is false and yet cast(bool)NaN is true though is just attrocious though. We aren't source compatible with C like C++ is, and yet we're still bound by it in so many small, stupid ways - largely because of the risk of ported code going badly.
>
> I think some of the float semantics aren't in the standard, but in IEEE754. But many languages have picked up many of C's not-so-great design characteristics. I think largely because people who write their own compilers tend to program in C… so more cultural than rational.

In D's case, Walter consciously tried to make sure that C code was either valid D code with the same semantics or that it wasn't valid D code so that you wouldn't get subtle errors when porting code from C to D. We aren't quite there (e.g. the semantics of a function parameter that's a static array aren't the same), but we're close. His reasoning makes a lot of sense, but it also means that we're still beholden to some of C's unsavory choices - albeit nowhere near as many as C++ is. So, in D's case at least, the decision to match C's semantics was very much rational. However, I'm sure that it's true that a number of the design decisions in D stem from the fact that both Walter and Andrei come from C/C++, and so they're going to tend to make design decisions similar to C/C++ by default. So, D ends up being different when there's a feature that's being purposefully designed to be different from C/C++, but it tends to be similar when there wasn't a strong reason to do something differently from C/C++.

- Jonathan M Davis


October 30, 2017
On Monday, 30 October 2017 at 22:42:48 UTC, Jonathan M Davis wrote:
> However, I'm sure that it's true that a number of the design decisions in D stem from the fact that both Walter and Andrei come from C/C++, and so they're going to tend to make design decisions similar to C/C++ by default. So, D ends up being different when there's a feature that's being purposefully designed to be different from C/C++, but it tends to be similar when there wasn't a strong reason to do something differently from C/C++.

But as we can see from this discussion of the elvis-operator those "rough edges" becomes viral over time as you add more features. So, whiley some rough edges might not be so visible when you have few features, they might be amplified as you add more features.  C++ is a pretty good example of this. They add new stuff that tries to iron out some of the rough spots, and are fairly successful at it, but they have to do it in ways where they end up with features clashing or syntactical annoyances. I haven't used Rust much, but it is interesting that they managed to stay out of the C-mold. Most other main-stream compiled languages has not.

Anyway, it often takes several years of practice to discover that neat features aren't so good after all. I probably wrote much more terse C code in the beginning. I also have changed my ways with C++, too much sigils so now I am using "and" and "or" for booleans. Too much reuse of "&&" and "&" makes code less readable. As languages get more complex feature-wise I think it becomes ever more important to streamline. Which is kinda the opposite of what happens when you let the design over decades. (so you have to put more work into streamlining how you write code).



October 30, 2017
On Monday, 30 October 2017 at 23:09:43 UTC, Ola Fosheim Grøstad wrote:
> Which is kinda the opposite of what happens when you let the design over decades. (so you have to put more work into streamlining how you write code).

I meant to say that this is the opposite of what happens when you let the language design evolve over years, so at the end the programmers have to compensate by focusing more on streamlining the aesthetics of their code…
October 31, 2017
On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
> Walter and I decided to kick-off project Elvis for adding the homonym operator to D.
>
> [...]
>
> Thanks,
>
> Andrei

The Elvis operator's purpose is to make working with null easier, but isn't null "The Billion Dollar Mistake"? :@
October 31, 2017
On Tuesday, 31 October 2017 at 08:15:24 UTC, Mark wrote:
> On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
>> Walter and I decided to kick-off project Elvis for adding the homonym operator to D.
>>
>> [...]
>>
>> Thanks,
>>
>> Andrei
>
> The Elvis operator's purpose is to make working with null easier, but isn't null "The Billion Dollar Mistake"? :@

Null is not the problem. The usage of types that can be null is the problem.

Although only concepts, these will solve most issues with null references.

https://github.com/visionlang/vsl/wiki/%2316-Null-safety
https://github.com/visionlang/vsl/wiki/%2325-not-null-types
https://github.com/visionlang/vsl/wiki/%2336-Error-Handling#nothrow

November 01, 2017
On Tuesday, 31 October 2017 at 19:39:17 UTC, bauss wrote:
> On Tuesday, 31 October 2017 at 08:15:24 UTC, Mark wrote:
>> On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
>>> Walter and I decided to kick-off project Elvis for adding the homonym operator to D.
>>>
>>> [...]
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> The Elvis operator's purpose is to make working with null easier, but isn't null "The Billion Dollar Mistake"? :@
>
> Null is not the problem. The usage of types that can be null is the problem.
>
> Although only concepts, these will solve most issues with null references.
>
> https://github.com/visionlang/vsl/wiki/%2316-Null-safety
> https://github.com/visionlang/vsl/wiki/%2325-not-null-types
> https://github.com/visionlang/vsl/wiki/%2336-Error-Handling#nothrow

I don't know... Personally I prefer Haskell's approach with Option types, but maybe it's too late to add something like that to D.
November 02, 2017
On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
> Walter and I decided to kick-off project Elvis for adding the homonym operator to D.

I'd like to mention null-coalescing assignment syntax. Perl has `$a //= $b`, and PHP has voted to support `$a ??= $b`, expanding to `$a = $a ?? $b`. Rationale:

// The following lines are doing the same
$this->request->data['comments']['user_id'] = $this->request->data['comments']['user_id'] ?? 'value';
// Instead of repeating variables with long names, the equal coalesce operator is used
$this->request->data['comments']['user_id'] ??= 'value';

https://wiki.php.net/rfc/null_coalesce_equal_operator

I expect D could do the same with `a ?:= b` or use the `??` operator syntax.

Just from memory, I think I would use null coalescing assignments more than null coalescing comparisons.