www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Project Elvis

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter and I decided to kick-off project Elvis for adding the homonym 
operator to D.

Razvan Nitu has already done a good part of the work:

https://github.com/dlang/dmd/pull/7242
https://github.com/dlang/dlang.org/pull/1917
https://github.com/dlang/dlang.org/pull/1918

What's needed is a precise DIP that motivates the feature properly and 
provides a good proposal for it. I'm no fan of bureaucracy but we really 
need to be pedantic about introducing language features. Walter argued 
thusly in a PR, and I agree:

"I'm concerned that the elvis operator is not well understood, and we 
shouldn't be designing it in the comments section here. A DIP needs to 
be written. Things like operator precedence, side effects, type 
resolution, comparison with the operator in other languages, grammar 
changes, lvalues, how it would appear in the generated .di file if it 
isn't its own operator, etc., should be addressed."

A lowering looks like the straightforward approach, of the kind:

expr1 ?: expr2

==>

(x => x ? x : expr2)(expr1)

Who wants to join Razvan in Project Elvis?


Thanks,

Andrei
Oct 28 2017
next sibling parent reply bauss <jj_1337 live.dk> writes:
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.

 [...]
This is honestly going to be a great addition.
Oct 28 2017
parent Daniel Kozak <kozzi11 gmail.com> writes:
Wait? You are saying D does not support this yet? Wow :D. I have been using
this so often in work (PHP) so I can beleive I have not miss this

On Sat, Oct 28, 2017 at 2:39 PM, bauss via Digitalmars-d <
digitalmars-d puremagic.com> 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.

 [...]
This is honestly going to be a great addition.
Oct 28 2017
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu 
wrote:
 expr1 ?: expr2
So, what will the member function be called? «opElvis»? No…
Oct 29 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On Sunday, 29 October 2017 at 10:08:41 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei 
 Alexandrescu wrote:
 expr1 ?: expr2
So, what will the member function be called? «opElvis»? No…
opCast for bool. -Steve
Oct 29 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer 
wrote:
 So, what will the member function be called? «opElvis»? No…
opCast for bool.
That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.
Oct 29 2017
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 14:27:34 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 29 October 2017 at 11:23:19 UTC, Steven 
 Schveighoffer wrote:
 So, what will the member function be called? «opElvis»? No…
opCast for bool.
That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.
That breaks down if you want do filter out invalid values where zero is a valid value. For instance if you have an integer type that tracks overflow: calc(maybe_overflow_integer :? 0) So casting to bool is a poor choice for the typical use context.
Oct 29 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/29/17 10:35 AM, Ola Fosheim Grøstad wrote:
 On Sunday, 29 October 2017 at 14:27:34 UTC, Ola Fosheim Grøstad wrote:
 On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer wrote:
 So, what will the member function be called? «opElvis»? No…
opCast for bool.
That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.
That breaks down if you want do filter out invalid values where zero is a valid value. For instance if you have an integer type that tracks overflow: calc(maybe_overflow_integer :? 0) So casting to bool is a poor choice for the typical use context.
I would have expected Nullable!int to fit the bill, but unfortunately, opCast(bool) doesn't work on a null Nullable. But certainly you can construct a type that does work. -Steve
Oct 29 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 15:57:19 UTC, Steven Schveighoffer 
wrote:
 I would have expected Nullable!int to fit the bill, but 
 unfortunately, opCast(bool) doesn't work on a null Nullable.

 But certainly you can construct a type that does work.
The right thing to do is to create a type that you cannot cast to bool, but where you can test for invalid values and substitute in a default. Forcing people to have a boolean interpretation of a type mean valid/invalid state has viral consequences. It means that if the type has a zero value then a boolean interpretation of zero now should give true. That's not good for generic code. Float and NaN is another use case.
Oct 29 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/29/17 12:29 PM, Ola Fosheim Grøstad wrote:
 On Sunday, 29 October 2017 at 15:57:19 UTC, Steven Schveighoffer wrote:
 I would have expected Nullable!int to fit the bill, but unfortunately, 
 opCast(bool) doesn't work on a null Nullable.

 But certainly you can construct a type that does work.
The right thing to do is to create a type that you cannot cast to bool, but where you can test for invalid values and substitute in a default.
This is pretty simple, the if(x) provides a mechanism to check called "casting to bool". That doesn't mean it will shoehorn bool into the expression. In fact, the elvis operator provides a perfect way to type the result with the "common type" rules of D. The way to do it is to make a type that checks whether the expression is valid or not, makes that into a bool, and then provides the real expression to the result.
 Forcing people to have a boolean interpretation of a type mean 
 valid/invalid state has viral consequences. It means that if the type 
 has a zero value then a boolean interpretation of zero now should give 
 true. That's not good for generic code.
It's actually perfect for generic code. If you need something other than the current "0 means false" behavior (like for instance int), then you wrap in a type that opCast!bool means what you want. It should work just like a pointer. In swift this is exactly what the ? operator does. I just wish Nullable worked this way, I'm surprised it doesn't. -Steve
Oct 29 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 20:05:08 UTC, Steven Schveighoffer 
wrote:
 It's actually perfect for generic code. If you need something 
 other than the current "0 means false" behavior (like for 
 instance int), then you wrap in a type that opCast!bool means 
 what you want.
I think we just have to agree that we disagree. Generic programming relies on consistent protocols. So, you generally don't want 0 to be considered as an invalid value. Because of the defaults in D, cast(bool) isn't really all that useful. It would have been better if the default was to deny casting to bool, but that is too late as D has decided to be too close to C on so many levels, so it would be a bad idea to diverge from C for that now. So the next best thing is to let the programmer specify that something is invalid with some other means than opCast to bool. *shrug*
Oct 29 2017
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 29 October 2017 at 20:15:41 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 29 October 2017 at 20:05:08 UTC, Steven 
 Schveighoffer wrote:
 It's actually perfect for generic code. If you need something 
 other than the current "0 means false" behavior (like for 
 instance int), then you wrap in a type that opCast!bool means 
 what you want.
I think we just have to agree that we disagree. Generic programming relies on consistent protocols. So, you generally don't want 0 to be considered as an invalid value. Because of the defaults in D, cast(bool) isn't really all that useful. It would have been better if the default was to deny casting to bool, but that is too late as D has decided to be too close to C on so many levels, so it would be a bad idea to diverge from C for that now. So the next best thing is to let the programmer specify that something is invalid with some other means than opCast to bool. *shrug*
But casting to bool is what you use to tell whether something is valid or not. true = valid, false = invalid. If you want 0 to be valid for a type then you wrap around it with opCast. Ex. --- import std.stdio; struct MyInt { int value; bool opCast(T : bool)() { return value >= 0; } } void main() { MyInt a = MyInt(1); MyInt b = MyInt(0); MyInt c = MyInt(-1); if (a) writeln("a is valid"); if (b) writeln("b is valid"); if (c) writeln("c is valid"); } --- Output: a is valid b is valid
Oct 29 2017
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 20:37:21 UTC, bauss wrote:
 But casting to bool is what you use to tell whether something 
 is valid or not.

 true = valid, false = invalid.
Not really. In mathematics 0 and 1 can be considered as "true" and "false" for a 2-value calculus, while you might reserve ⊤ and ⊥ for true and false in the logic you use to reason about that calculus. Which is why some languages assumes an equality between 0 and true and 1 and false, but that does not by necessity suggest valid/invalid. On the other hand. For things like Unix function call return values -1 is often used to signify an invalid result, and 0 does not signify failure. So if you want strict typing, you have to do something else. Because C (and thus D) takes the mathematical view on the relationship between integers and bools and propagate that view to all other basic types (e.g. floats). Ola.
Oct 29 2017
parent reply w0rp <devw0rp gmail.com> writes:
One man's valid value is another man's invalid value. You can't 
test for a general concept of "invalid," as you need context. You 
can test for "falsy" with no context.
Oct 29 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 October 2017 at 00:10:13 UTC, w0rp wrote:
 One man's valid value is another man's invalid value. You can't 
 test for a general concept of "invalid," as you need context. 
 You can test for "falsy" with no context.
No, associating the numeral "0" with "false" is forcing a particular interpretation of int as representing a count of something. That is not an inate quality of the integer programming language type as such. For instance, there is no reason for "0 fahrenheit" to be "false". Only if "0" represents the "empty set" would that interpretation make some sense. Yes, you can obviously have a general concept of invalid in a strict typing system.
Oct 29 2017
prev sibling parent Satoshi <satoshi rikarin.org> writes:
On Sunday, 29 October 2017 at 20:37:21 UTC, bauss wrote:
 On Sunday, 29 October 2017 at 20:15:41 UTC, Ola Fosheim Grøstad 
 wrote:
 [...]
But casting to bool is what you use to tell whether something is valid or not. true = valid, false = invalid. If you want 0 to be valid for a type then you wrap around it with opCast. Ex. --- import std.stdio; struct MyInt { int value; bool opCast(T : bool)() { return value >= 0; } } void main() { MyInt a = MyInt(1); MyInt b = MyInt(0); MyInt c = MyInt(-1); if (a) writeln("a is valid"); if (b) writeln("b is valid"); if (c) writeln("c is valid"); } --- Output: a is valid b is valid
TL;DR This could be done by maybe monad. int? a = 0; if (a) writeln("a is valid"); BTW: Thanks for implementing the Elvis feature.
Oct 30 2017
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, October 29, 2017 14:27:34 Ola Fosheim Grøstad via Digitalmars-d 
wrote:
 On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer

 wrote:
 So, what will the member function be called? «opElvis»? No…
opCast for bool.
That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.
opCast with bool is precisely how you already provide overloads for dealing with every other place in the language that a boolean condition is used - the ternary operator, assertions, if statements, while loops, and for loops (which I think is everything, but I could have missed something). As proposed thus far, the Elvis operator is just the ternary operator where the condition is reused as the first branch, so having it work with opCast fits in perfectly with everything else. What would you be looking to do that does not fit in with this? - Jonathan M Davis
Oct 29 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 14:37:57 UTC, Jonathan M Davis 
wrote:
 everything, but I could have missed something). As proposed 
 thus far, the Elvis operator is just the ternary operator where 
 the condition is reused as the first branch, so having it work 
 with opCast fits in perfectly with everything else.
I understand that it is being defined as a short hand for the ordinary ternary operator, but if you look at the use context the elvis-operator tend to be used to filter out invalid state. So if casting to bool would test for validity then it would make more sense, but that is not the general case...
 What would you be looking to do that does not fit in with this?
I think it would be better to have a test for validity and use that for substituting in default values (which is what the elvis operator is typically used for).
Oct 29 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, October 29, 2017 16:18:43 Ola Fosheim Grstad via Digitalmars-d 
wrote:
 On Sunday, 29 October 2017 at 14:37:57 UTC, Jonathan M Davis

 wrote:
 everything, but I could have missed something). As proposed
 thus far, the Elvis operator is just the ternary operator where
 the condition is reused as the first branch, so having it work
 with opCast fits in perfectly with everything else.
I understand that it is being defined as a short hand for the ordinary ternary operator, but if you look at the use context the elvis-operator tend to be used to filter out invalid state. So if casting to bool would test for validity then it would make more sense, but that is not the general case...
 What would you be looking to do that does not fit in with this?
I think it would be better to have a test for validity and use that for substituting in default values (which is what the elvis operator is typically used for).
And what does testing for validity even mean? Doesn't that depend on the type? I would argue that with regards to the built-in types what cast(bool) does for them is as close to checking for validity as you're going to get, and for user-defined types, they can then just overload opCast!bool to mean whatever they want so long as the result is true or false. In general, if you're looking to check whether something is valid using ?:, I would think that you'd want to be doing the same check with stuff like if statements anyway. So, it sounds to me like overloading opCast!bool would work just fine. - Jonathan M Davis
Oct 29 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis 
wrote:
 valid using ?:, I would think that you'd want to be doing the 
 same check with stuff like if statements anyway. So, it sounds 
 to me like overloading opCast!bool would work just fine.
If you try to do: some_float ?: 0.0 then it will do nothing as cast(bool)std.math.NaN(0) => true But that is just one of many possible examples. The elvis operator as proposed does not match on nullity / invalid state.
Oct 29 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grstad via Digitalmars-d 
wrote:
 On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis

 wrote:
 valid using ?:, I would think that you'd want to be doing the
 same check with stuff like if statements anyway. So, it sounds
 to me like overloading opCast!bool would work just fine.
If you try to do: some_float ?: 0.0 then it will do nothing as cast(bool)std.math.NaN(0) => true
NaN is supposed to always be false.
 But that is just one of many possible examples. The elvis
 operator as proposed does not match on nullity / invalid state.
Well, the closest that the language has to that is cast(bool). There is nothing else generic for anything along those lines. If you want something else, then just use the ternary operator with whatever condition you want to be testing. It works just fine and isn't much longer. Personally, I don't think that the Elvis operator is worth much - at least not in D. Idiomatic D code doesn't use classes much. Dynamic arrays largely conflate null with empty. Very little does anything with null - especially if you're writing range-based code - and I've rarely seen code where x ? x : y was used. The closest that I've typically seen or done to x ? x : y is if(auto var = foo()) { } and that's not useful for much beyond dealing with functions that return error codes or getting values from associative arrays. And it's not like using the ternary operator is very verbose. But the whole idea of "check if this is valid, if it is use it, and if it isn't, use a default" simply isn't an idiom that I use much, and I don't think that it's very common in Phobos. I also tend to prefer being explicit about conditions, so I don't typically rely on things like cast(bool) on types, and that's exactly the sort of thing that the Elvis operator would rely on whether it used cast(bool) or it was overloaded as its own operator like you seem to want. So, I really don't think that there's any point in adding the Elvis operator, but there are some folks here who seem to think that it's a great loss that we don't have it, because they're used to writing stuff like that in languages like C#, which do way more with classes and null than D code typically does. - Jonathan M Davis
Oct 29 2017
parent reply Nemanja Boric <4burgos gmail.com> writes:
On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis 
wrote:
 On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via 
 Digitalmars-d wrote:
 On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis

 wrote:
 valid using ?:, I would think that you'd want to be doing 
 the same check with stuff like if statements anyway. So, it 
 sounds to me like overloading opCast!bool would work just 
 fine.
If you try to do: some_float ?: 0.0 then it will do nothing as cast(bool)std.math.NaN(0) => true
NaN is supposed to always be false.
OT, but I had to :-) ``` void main() { import std.stdio; float x; x? writeln("Oh no, a NaN!") : writeln("All good."); } ``` Same happens for assert(float.nan) - it doesn't fail.
Oct 29 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, October 29, 2017 17:35:25 Nemanja Boric via Digitalmars-d wrote:
 On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis

 wrote:
 On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grstad via

 Digitalmars-d wrote:
 On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis

 wrote:
 valid using ?:, I would think that you'd want to be doing
 the same check with stuff like if statements anyway. So, it
 sounds to me like overloading opCast!bool would work just
 fine.
If you try to do: some_float ?: 0.0 then it will do nothing as cast(bool)std.math.NaN(0) => true
NaN is supposed to always be false.
OT, but I had to :-) ``` void main() { import std.stdio; float x; x? writeln("Oh no, a NaN!") : writeln("All good."); } ``` Same happens for assert(float.nan) - it doesn't fail.
Sounds like a bug to me. NaN is supposed to be false whenever it's used in a comparison. If it it's true when cast directly to bool, then that's inconsistent. - Jonathan M Davis
Oct 29 2017
next sibling parent reply Nemanja Boric <4burgos gmail.com> writes:
On Sunday, 29 October 2017 at 18:02:25 UTC, Jonathan M Davis 
wrote:
 On Sunday, October 29, 2017 17:35:25 Nemanja Boric via 
 Digitalmars-d wrote:
 On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis

 wrote:
 On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via

 Digitalmars-d wrote:
 On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis

 wrote:
 valid using ?:, I would think that you'd want to be doing 
 the same check with stuff like if statements anyway. So, 
 it sounds to me like overloading opCast!bool would work 
 just fine.
If you try to do: some_float ?: 0.0 then it will do nothing as cast(bool)std.math.NaN(0) => true
NaN is supposed to always be false.
OT, but I had to :-) ``` void main() { import std.stdio; float x; x? writeln("Oh no, a NaN!") : writeln("All good."); } ``` Same happens for assert(float.nan) - it doesn't fail.
Sounds like a bug to me. NaN is supposed to be false whenever it's used in a comparison. If it it's true when cast directly to bool, then that's inconsistent. - Jonathan M Davis
We've already reported this as a bug (I actually got quite burned on it, trusting assert(float_value) to prevent NaN's escaping the function), but there were different opinions on this, so it never got anywhere: https://issues.dlang.org/show_bug.cgi?id=13489
Oct 29 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/29/17 3:10 PM, Nemanja Boric wrote:
 We've already reported this as a bug (I actually got quite burned on it, 
 trusting assert(float_value) to prevent NaN's escaping the function), 
 but there were different opinions on this, so it never got anywhere: 
 https://issues.dlang.org/show_bug.cgi?id=13489
Wow, interesting dialog there. 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! 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. -Steve
Oct 30 2017
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, October 30, 2017 11:04:32 Steven Schveighoffer via Digitalmars-d 
wrote:
 On 10/29/17 3:10 PM, Nemanja Boric wrote:
 We've already reported this as a bug (I actually got quite burned on it,
 trusting assert(float_value) to prevent NaN's escaping the function),
 but there were different opinions on this, so it never got anywhere:
 https://issues.dlang.org/show_bug.cgi?id=13489
Wow, interesting dialog there. 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! 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. I avoid floating point types on general principle though - not just in if statements. I'll use them when I need them, but if I can reasonably do something with an integral type instead, I will, because I don't want to deal with the inaccuracies of FP math. 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. - Jonathan M Davis
Oct 30 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Oct 30 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Oct 30 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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).
Oct 30 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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…
Oct 30 2017
prev sibling next sibling parent crimaniak <crimaniak gmail.com> writes:
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.
Oct 30 2017
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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!
Oct 30 2017
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 October 2017 at 18:02:25 UTC, Jonathan M Davis 
wrote:
 Sounds like a bug to me. NaN is supposed to be false whenever 
 it's used in a comparison. If it it's true when cast directly 
 to bool, then that's inconsistent.
It is consistent with C...
Oct 29 2017
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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.

 Razvan Nitu has already done a good part of the work:

 https://github.com/dlang/dmd/pull/7242
 https://github.com/dlang/dlang.org/pull/1917
 https://github.com/dlang/dlang.org/pull/1918
Is it going to be something similar (or the same) as in Kotlin? (Reference: https://kotlinlang.org/docs/reference/null-safety.html#elvis-operator ) I see from comments that different people think of it in a different way. I suggest them to read this section from Kotlin docs to understand the reasoning behind the elvis operator.
Oct 30 2017
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/30/17 7:32 AM, Dejan Lekic 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.

 Razvan Nitu has already done a good part of the work:

 https://github.com/dlang/dmd/pull/7242
 https://github.com/dlang/dlang.org/pull/1917
 https://github.com/dlang/dlang.org/pull/1918
Is it going to be something similar (or the same) as in Kotlin? (Reference: https://kotlinlang.org/docs/reference/null-safety.html#elvis-operator ) I see from comments that different people think of it in a different way. I suggest them to read this section from Kotlin docs to understand the reasoning behind the elvis operator.
From looking quickly at that, but not having any experience with Kotlin (but having some experience with Swift), I think this really requires a concept of Nullable types being a builtin feature. The idea is to have something that always results in a non-null value. Swift uses the operator ?? to do the same thing (search for ?? on this page: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html) I think D has the capability of doing the same thing, even with Nullable being a library type, but would have to be pervasive in usage to look like Kotlin. At least the operator itself fits into the usage of Null or not types. Of course, the D version is much more adaptable, as any concept of "Null" or "Invalid" can be ascribed to a type via the opCast(bool) function. -Steve
Oct 30 2017
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/17 7:32 AM, Dejan Lekic 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.

 Razvan Nitu has already done a good part of the work:

 https://github.com/dlang/dmd/pull/7242
 https://github.com/dlang/dlang.org/pull/1917
 https://github.com/dlang/dlang.org/pull/1918
Is it going to be something similar (or the same) as in Kotlin? (Reference: https://kotlinlang.org/docs/reference/null-safety.html#elvis-operator ) I see from comments that different people think of it in a different way. I suggest them to read this section from Kotlin docs to understand the reasoning behind the elvis operator.
The principle of least astonishment indicates we should do what the lowering does: expr1 ?: expr2 ==> (x => x ? x : expr2)(expr1) An approach that does things any differently would have a much more difficult time. It is understood (and expected) that other languages have subtly different takes on the operator. Andrei
Oct 30 2017
parent MrSmith <mrsmith33 yandex.ru> writes:
On Monday, 30 October 2017 at 19:46:54 UTC, Andrei Alexandrescu 
wrote:
 I see from comments that different people think of it in a 
 different way. I suggest them to read this section from Kotlin 
 docs to understand the reasoning behind the elvis operator.
The principle of least astonishment indicates we should do what the lowering does: expr1 ?: expr2 ==> (x => x ? x : expr2)(expr1) An approach that does things any differently would have a much more difficult time. It is understood (and expected) that other languages have subtly different takes on the operator. Andrei
I may add that the same logic is used in .get(key, defaultValue) method of Associative Arrays
Nov 05 2017
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
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"? :
Oct 31 2017
parent reply bauss <jj_1337 live.dk> writes:
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
Oct 31 2017
parent Mark <smarksc gmail.com> writes:
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.
Nov 01 2017
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
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.
Nov 02 2017
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 02, 2017 at 12:50:47PM +0000, Nick Treleaven via Digitalmars-d
wrote:
[..]
 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`.
[...]
 I expect D could do the same with `a ?:= b` or use the `??` operator syntax.
Isn't the `??` syntax what the Elvis operator `?:` supposed to do? Given that the proposed Elvis operator would be `?:`, I'd expect the corresponding assignment operator would be `?:=`, in following the pattern of the other op-assign operators.
 Just from memory, I think I would use null coalescing assignments more
 than null coalescing comparisons.
If we're going to have one of them, might as well have both. T -- I think the conspiracy theorists are out to get us...
Nov 02 2017
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, November 02, 2017 09:46:06 H. S. Teoh via Digitalmars-d wrote:
 On Thu, Nov 02, 2017 at 12:50:47PM +0000, Nick Treleaven via Digitalmars-d
 wrote: [..]

 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`.
[...]
 I expect D could do the same with `a ?:= b` or use the `??` operator
 syntax.
Isn't the `??` syntax what the Elvis operator `?:` supposed to do? Given that the proposed Elvis operator would be `?:`, I'd expect the corresponding assignment operator would be `?:=`, in following the pattern of the other op-assign operators.
In a previous thread, it was stated that in other languages (no idea which ones), ?? tests specifically for null, whereas ?: tests for true. Other, related operators were discussed as well - including ?. - which if I understood correctly, allows you to call a member function only if the object isn't null. But going into other operators like that starts taking this well beyond the basic idea of shortening the ternary operator for the x ? x : y case like the elvis operator does, and for better or worse, that takes the DIP in a whole new direction. However, if we do add ?:, I think that it's pretty clear that some folks will be asking for stuff like ?. or ?:=, since I think that it's largely the case that the folks who want the elvis operator are interested in the related operators. However, their usefulness seems to be mostly predicated on the idea that you're doing a lot with class references or pointers which might be null and where you would want to do an operation with them if they're non-null and just skip that code if they're null. And given how little idiomatic D code uses classes, I don't know how useful they'll be in practice in D. It's likely to depend a lot on your coding style. I'm quite sure that I would find them borderline useless, but some of the folks who are highly interested in them may find a lot of use for them. I don't know. - Jonathan M Davis
Nov 02 2017
prev sibling next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
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.
It's easy to write in function form: auto orElse(T)(T a, lazy T b) { return a ? a : b; } writeln(args[1].length.orElse(fibonacci(50))); This version can also be specialized for things like Nullable, where you can't necessarily cast it safely to a boolean but have a check for validity. Is it that valuable to have an operator for it instead? As an aside, I believe feepingcreature had a custom infix operator for this sort of thing defined, so you could write: (a /or/ b /or/ c).doStuff(); The implementation (along with /and/) is left as an exercise to the reader.
Nov 05 2017
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 6 November 2017 at 00:20:09 UTC, Neia Neutuladh 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.
It's easy to write in function form: auto orElse(T)(T a, lazy T b) { return a ? a : b; } writeln(args[1].length.orElse(fibonacci(50))); This version can also be specialized for things like Nullable, where you can't necessarily cast it safely to a boolean but have a check for validity. Is it that valuable to have an operator for it instead? As an aside, I believe feepingcreature had a custom infix operator for this sort of thing defined, so you could write: (a /or/ b /or/ c).doStuff(); The implementation (along with /and/) is left as an exercise to the reader.
Sure you might be able to write it easily, but pretty much everyone writes a function like that in their projects and you don\t really know the implementation always and you have to remember the exact name or else you end up writing the function yourself in your project to make sure the implementation is exactly like that, which in fact turns out to be re-inventing the wheel. By having an official syntax for it, you don't end up with code duplication like that and the implementation details of the behavior is clear. Because in some implementation "orElse()" might only check if the value is null and not necessary if the value is true. Ex. one might implement it like: auto orElse(T)(T a, lazy T b) { return a !is null ? a : b; } Such implementation detail is not clear from the call-side. However with an official implementation you know exactly how it will behave and nothing is obscure like this.
Nov 05 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, November 06, 2017 07:10:43 bauss via Digitalmars-d wrote:
 On Monday, 6 November 2017 at 00:20:09 UTC, Neia Neutuladh 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.
It's easy to write in function form: auto orElse(T)(T a, lazy T b) { return a ? a : b; } writeln(args[1].length.orElse(fibonacci(50))); This version can also be specialized for things like Nullable, where you can't necessarily cast it safely to a boolean but have a check for validity. Is it that valuable to have an operator for it instead? As an aside, I believe feepingcreature had a custom infix operator for this sort of thing defined, so you could write: (a /or/ b /or/ c).doStuff(); The implementation (along with /and/) is left as an exercise to the reader.
Sure you might be able to write it easily, but pretty much everyone writes a function like that in their projects and you don\t really know the implementation always and you have to remember the exact name or else you end up writing the function yourself in your project to make sure the implementation is exactly like that, which in fact turns out to be re-inventing the wheel. By having an official syntax for it, you don't end up with code duplication like that and the implementation details of the behavior is clear. Because in some implementation "orElse()" might only check if the value is null and not necessary if the value is true. Ex. one might implement it like: auto orElse(T)(T a, lazy T b) { return a !is null ? a : b; } Such implementation detail is not clear from the call-side. However with an official implementation you know exactly how it will behave and nothing is obscure like this.
That might be an argument for having an official implementation, but it's not really an argument for why it should be built into the language; it could just as easily be in Phobos if that's all that matters. - Jonathan M Davis
Nov 06 2017
parent reply Satoshi <satoshi rikarin.org> writes:
On Monday, 6 November 2017 at 08:06:54 UTC, Jonathan M Davis 
wrote:
 On Monday, November 06, 2017 07:10:43 bauss via Digitalmars-d 
 wrote:
 On Monday, 6 November 2017 at 00:20:09 UTC, Neia Neutuladh 
 wrote:
 On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei

 Alexandrescu wrote:
 [...]
It's easy to write in function form: auto orElse(T)(T a, lazy T b) { return a ? a : b; } writeln(args[1].length.orElse(fibonacci(50))); This version can also be specialized for things like Nullable, where you can't necessarily cast it safely to a boolean but have a check for validity. Is it that valuable to have an operator for it instead? As an aside, I believe feepingcreature had a custom infix operator for this sort of thing defined, so you could write: (a /or/ b /or/ c).doStuff(); The implementation (along with /and/) is left as an exercise to the reader.
Sure you might be able to write it easily, but pretty much everyone writes a function like that in their projects and you don\t really know the implementation always and you have to remember the exact name or else you end up writing the function yourself in your project to make sure the implementation is exactly like that, which in fact turns out to be re-inventing the wheel. By having an official syntax for it, you don't end up with code duplication like that and the implementation details of the behavior is clear. Because in some implementation "orElse()" might only check if the value is null and not necessary if the value is true. Ex. one might implement it like: auto orElse(T)(T a, lazy T b) { return a !is null ? a : b; } Such implementation detail is not clear from the call-side. However with an official implementation you know exactly how it will behave and nothing is obscure like this.
That might be an argument for having an official implementation, but it's not really an argument for why it should be built into the language; it could just as easily be in Phobos if that's all that matters. - Jonathan M Davis
You need additional import for this verbose syntax https://en.wikipedia.org/wiki/Syntactic_sugar Why we have operators overloading when we could have Equals() and stuff like in java? Why we have arr ~= arr2 when we could have Array.mergeArrays(arr, arr2) instead? Look, this operator does not break anything. If you don't want to use it, just don't, but why do you force everyone else to not to use it, just because it is not adding anything "more valuable" than just better syntax?
Nov 06 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, November 06, 2017 09:26:24 Satoshi via Digitalmars-d wrote:
 Look, this operator does not break anything. If you don't want to
 use it, just don't, but why do you force everyone else to not to
 use it, just because it is not adding anything "more valuable"
 than just better syntax?
_Everything_ that is added to the language complicates it further. It's one more thing that everyone learning the language has to learn and know and potentially deal with in code. Obviously, some things are worth the extra complication, or we'd all be programming in C, but there is always a cost to adding something, and the feature needs to be worth that cost. Granted, the elvis operator as proposed is not all that complicated, but adding it does make the language that much more complex, and it really doesn't do much. All it does is take the expression x ? x : y and make it x ?: y It saves 2 characters plus the length of the variable name. That's it. And it's optimizing an idiom that isn't going to tend to show up much in idiomatic D code. It seems to be targeted primarily at code that does a lot with classes and is written in such a way that it's not clear whether a class reference should be null or not, whereas most D code doesn't do much with classes. Rather, it does a lot with ranges and structs on the stack. Obviously, some code uses classes, and I expect that some code would benefit from the elvis operator, but I dispute that it's a common enough idiom to merit being added the language. Personally, while I frequently use the ternary operator, I almost never end up with the left and middle branches being the same, which is the only place that the elvis operator would be useful. And I don't think that Phobos does it much either. So, unless a lot of D code out there is using a drastically different coding style that does a lot with null, the elvis operator will not help much D code. So, IMHO, the elvis operator adds very little value, and I'd just as soon not see the language complicated further without adding real value in the process. So, I'll argue against it, but ultimately, it's not my decision. Rather, it's up to Walter and Andrei, and they'll decide what they decide. But don't expect anyone not to be unhappy about a feature being added to the language when they don't think that the feature adds value, because there is always a cost to a new feature. The difference is that you think that the feature is worth the cost, not that the folks who don't want to use the feature don't have to pay the cost. - Jonathan M Davis
Nov 06 2017
next sibling parent reply Biotronic <simen.kjaras gmail.com> writes:
On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis 
wrote:
 x ? x : y

 and make it

 x ?: y

 It saves 2 characters plus the length of the variable name. 
 That's it.
I find I often use this in C# with a more complex expression on the left-hand side, like a function call. A quick search shows more than 2/3 of my uses are function calls or otherwise significantly more complex than a variable. Also, it works great in conjunction with the null conditional: foo.Select(a => bar(a, qux)).FirstOrDefault?.Name ?? "not found";
 It seems to be targeted primarily at code that does a lot with 
 classes and is written in such a way that it's not clear 
 whether a class reference should be null or not, whereas most D 
 code doesn't do much with classes.
In my C# code, it's used with strings and Nullable<T> more often than with classes. Given my own experience with the ?? operator, I'd argue it's probably not worth it without also including null conditional (?.). A quick search in a few projects indicate roughly half the uses of ?? also use ?.. -- Biotronic
Nov 06 2017
parent Nathan S. <no.public.email example.com> writes:
On Monday, 6 November 2017 at 12:25:06 UTC, Biotronic wrote:
 I find I often use this in C# with a more complex expression on 
 the left-hand side, like a function call. A quick search shows 
 more than 2/3 of my uses are function calls or otherwise 
 significantly more complex than a variable. Also, it works 
 great in conjunction with the null conditional:

 foo.Select(a => bar(a, qux)).FirstOrDefault?.Name ?? "not 
 found";

 It seems to be targeted primarily at code that does a lot with 
 classes and is written in such a way that it's not clear 
 whether a class reference should be null or not, whereas most 
 D code doesn't do much with classes.
In my C# code, it's used with strings and Nullable<T> more often than with classes. Given my own experience with the ?? operator, I'd argue it's probably not worth it without also including null conditional (?.). A quick search in a few projects indicate roughly half the uses of ?? also use ?.. -- Biotronic
Without including ".?", this proposed "Elvis operator" will just be ECMAScript-style "||". I think it will still be useful because "||" is useful, but it would be more elegant to just allow "a || b" to have the common type of "a" and "b" (which wouldn't change the truthiness of the expression) instead of introducing a new operator that is exactly like "||" except it doesn't force the result to be bool.
Nov 10 2017
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis 
wrote:
 All it does is take the expression

 x ? x : y

 and make it

 x ?: y
Yes, that is an issue because it means that typos no longer are caught. E.g. if you accidentally comment out or delete the second expression. Which is why I think ?? or some other choice would offer better usability.
 The difference is that you think that the feature is worth the 
 cost, not that the folks who don't want to use the feature 
 don't have to pay the cost.
Indeed.
Nov 06 2017
parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 6 November 2017 at 13:02:43 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis 
 wrote:
 All it does is take the expression

 x ? x : y

 and make it

 x ?: y
Yes, that is an issue because it means that typos no longer are caught. E.g. if you accidentally comment out or delete the second expression.
The commenting out case can be prevented by making ?: an actual operator, so ?/**/: would be an error. (Also I think it's regressive to argue invalid code becoming valid is a good reason to prevent introducing a feature).
 Which is why I think ?? or some other choice would offer better 
 usability.
I think ??= reads better than ?:=, which looks like Pascal assignment.
Nov 13 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 13 November 2017 at 14:44:55 UTC, Nick Treleaven wrote:
 The commenting out case can be prevented by making ?: an actual 
 operator, so ?/**/: would be an error.
Yes, that sounds reasonable.
 (Also I think it's regressive to argue invalid code becoming 
 valid is a good reason to prevent introducing a feature).
In terms of usability you want to catch typos so you want some redundancy, but I don't know whether this is a likely typo. But in general, it is possible to construct a language where all strings are valid programs. That would also mean that all typos would go un-noticed in that language.
Nov 13 2017
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis 
wrote:
 On Monday, November 06, 2017 09:26:24 Satoshi via Digitalmars-d 
 wrote:
 [...]
_Everything_ that is added to the language complicates it further. It's one more thing that everyone learning the language has to learn and know and potentially deal with in code. Obviously, some things are worth the extra complication, or we'd all be programming in C, but there is always a cost to adding something, and the feature needs to be worth that cost. [...]
I have gone through all the threads and none of the comment argues why we REALLY need Elvis in D. Seem to me like some kind of "language peer influence" or something. It can be done as a library and using ternary works (more expressive). The problems we need to be solving ...I'm gonna cry :( ...we aren't talking about.
Nov 07 2017
next sibling parent codephantom <me noyb.com> writes:
On Wednesday, 8 November 2017 at 07:32:05 UTC, aberba wrote:
 I have gone through all the threads and none of the comment 
 argues why we REALLY need Elvis in D. Seem to me like some kind 
 of "language peer influence" or something.
Presumably, it's just a more 'elegant' (less verbose) way of doing something that can already be done. -- taken from: https://kotlinlang.org/docs/reference/null-safety.html#elvis-operator val l: Int = if (b != null) b.length else -1 Along with the complete if-expression, this can be expressed with the Elvis operator, written ?:: val l = b?.length ?: -1 ---------- But I can understand the first example really easily. The second example, with the elvis operator, I have to spend 'more time' making sure I've interepreted those little symbols correctly. I don't like this syntactic 'elegance' at all. The human brain has too much trouble with it, unless it comes into contact with it often. So as someone once said, "one has to be very suspicious of the elegant solution" - Butler Lampson 1992.
Nov 08 2017
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 8 November 2017 at 07:32:05 UTC, aberba wrote:
 I have gone through all the threads and none of the comment 
 argues why we REALLY need Elvis in D. Seem to me like some kind 
 of "language peer influence" or something.

 It can be done as a library and using ternary works (more 
 expressive). The problems we need to be solving ...I'm gonna 
 cry :( ...we aren't talking about.
I'd say add canonical versions of the relevant functions to Phobos first and then if really popular add to language later.
Nov 08 2017
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/05/2017 07:20 PM, Neia Neutuladh 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.
It's easy to write in function form:   auto orElse(T)(T a, lazy T b)   {     return a ? a : b;   }   writeln(args[1].length.orElse(fibonacci(50))); This version can also be specialized for things like Nullable, where you can't necessarily cast it safely to a boolean but have a check for validity. Is it that valuable to have an operator for it instead? As an aside, I believe feepingcreature had a custom infix operator for this sort of thing defined, so you could write:   (a /or/ b /or/ c).doStuff(); The implementation (along with /and/) is left as an exercise to the reader.
If a DIP emerges, it would need to present such alternatives and argue how it adds value over them. -- Andrei
Nov 06 2017
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/28/17 04:38, Andrei Alexandrescu wrote:
 Walter and I decided to kick-off project Elvis for adding the homonym
 operator to D.

 Razvan Nitu has already done a good part of the work:

 https://github.com/dlang/dmd/pull/7242
 https://github.com/dlang/dlang.org/pull/1917
 https://github.com/dlang/dlang.org/pull/1918

 What's needed is a precise DIP that motivates the feature properly and
 provides a good proposal for it. I'm no fan of bureaucracy but we really
 need to be pedantic about introducing language features. Walter argued
 thusly in a PR, and I agree:

 "I'm concerned that the elvis operator is not well understood, and we
 shouldn't be designing it in the comments section here. A DIP needs to
 be written. Things like operator precedence, side effects, type
 resolution, comparison with the operator in other languages, grammar
 changes, lvalues, how it would appear in the generated .di file if it
 isn't its own operator, etc., should be addressed."

 A lowering looks like the straightforward approach, of the kind:

 expr1 ?: expr2

 ==>

 (x => x ? x : expr2)(expr1)

 Who wants to join Razvan in Project Elvis?


 Thanks,

 Andrei
C# has extensive experience with this operator and I think it would be wise to study the history of what they did and why the did it. NOTE: I understand that other languages have it, and there are variations on the theme, but C# has many similarities to D and extensive "in practice" idioms. C# got the Elvis operator before it got the Null Conditional operator. In C# it only covers the case: a == null. The reason is that in practice most devs only use it like so: a != null ? a : b. The funny thing is that it was almost never used. Some years later the C# team introduces the Null-Conditional operator: ?. which allows you to write: obj1?.obj2?.prop3 ?? constant. NOW people start using Null Coalescing all over the place. I am all for the Elvis operator, however I have two reservations about it. The first is that I don't see much use for it without a null-conditional. The second is that the current proposed syntax ?: is MUCH to easily confused with ?. This is not easy to read: obj1?.obj2?.prop3?:constant. When designing syntax sugar, ergonomics are very important, otherwise people won't use it. Microsoft spent a LOT of time and treasure to learn these lessons for us. I see no reason to ignore them just because "we don't like Microsoft" My proposal would be to copy what MSFT did, expect that I would I would introduce both operators at the same time. Syntax as follows: obj1?.obj2?.prop3 ?? constant In practice I don't see much use of the idiom outside of null's. The ONLY other thing that would work there is a boolean field and you might as well just return the boolean itself because the return values have to match types. For example: return obj1.bool ?? obj2 //Error: incorrect return type return obj1 ?? obj2 // Pass: if same type I cannot actually imagine a scenario outside of objects (including strings) where you could actually use it since the left-hand side MUST evaluate to a boolean. Also, I am going to start repeating this mantra: Just because something CAN be done in the library, does not mean it SHOULD be done in the library. Ergonomics matters. Yes, I understand that D is a powerful language, but Syntax Sugar has it's place in taking common idioms and standardizing them in the language itself (English is loaded with stuff like that) so that everyone can "speak the same language". -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Nov 06 2017
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 On 10/28/17 04:38, Andrei Alexandrescu wrote:
 Walter and I decided to kick-off project Elvis for adding the 
 homonym
 operator to D.

 Razvan Nitu has already done a good part of the work:

 https://github.com/dlang/dmd/pull/7242
 https://github.com/dlang/dlang.org/pull/1917
 https://github.com/dlang/dlang.org/pull/1918
Some years later the C# team introduces the Null-Conditional operator: ?. which allows you to write: obj1?.obj2?.prop3 ?? constant. NOW people start using Null Coalescing all over the place.
So C# embraced the Null. Everything is nullable and you are expected to ?. proof it if you don’t know in advance. In contrast other languages (e.g. Scala) decided to discourage the use of null in favor of algebraic type Option!T and even remove the null all together.
 I am all for the Elvis operator, however I have two 
 reservations about it.
To me the biggest reservation is “embracing the null” that this entails. In other words since we dedicate a feature to support nulls that indicates null return is an endorsed aproach to e.g. model APIs and libraries that deal with optional values. I’d argue this NOT what we want. Nullability is best captured in the typesystem even if in the form of Nullable!T.
Nov 06 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-11-06 20:40, Dmitry Olshansky wrote:

 I’d argue this NOT what we want. Nullability is best captured in the 
 typesystem even if in the form of Nullable!T.
Yeah, it would be better if the elvis operator good integrate with a nullable/option type as well in addition to null. -- /Jacob Carlborg
Nov 06 2017
parent reply Meta <jared771 gmail.com> writes:
On Monday, 6 November 2017 at 19:55:13 UTC, Jacob Carlborg wrote:
 On 2017-11-06 20:40, Dmitry Olshansky wrote:

 I’d argue this NOT what we want. Nullability is best captured 
 in the typesystem even if in the form of Nullable!T.
Yeah, it would be better if the elvis operator good integrate with a nullable/option type as well in addition to null.
What's the point when we can already do it easily in a library, and arguably with better ergonomics? (http://forum.dlang.org/post/fshlmahxfaeqtwjbjouz forum.dlang.org) auto tree = new Node(1, new Node(2), new Node(3, null, new Node(4) ) ); import std.stdio; writeln(safeDeref(tree).right.right.val.orElse(-1)); writeln(safeDeref(tree).left.right.left.right.orElse(null)); writeln(safeDeref(tree).left.right.left.right.val.orElse(-1)); vs. writeln(tree?. right?.right?.val ?: -1); writeln(tree?.left?.right?.left?.right); writeln(tree?.left?.right?.left?.right?.val ?: -1); The functionality is probably a good idea, but a library solution is doable today without any acrobatics.
Nov 06 2017
parent reply user1234 <user1234 12.12> writes:
On Monday, 6 November 2017 at 20:14:17 UTC, Meta wrote:
 [...]
 import std.stdio;
 writeln(safeDeref(tree).right.right.val.orElse(-1));
 writeln(safeDeref(tree).left.right.left.right.orElse(null));
 writeln(safeDeref(tree).left.right.left.right.val.orElse(-1));

 vs.

 writeln(tree?. right?.right?.val ?: -1);
 writeln(tree?.left?.right?.left?.right);
 writeln(tree?.left?.right?.left?.right?.val ?: -1);

 The functionality is probably a good idea, but a library 
 solution is doable today without any acrobatics.
Show me a library solution that works fine with IDE completion (so for the safe navigation operator, not the Elvis one).
Nov 07 2017
next sibling parent Meta <jared771 gmail.com> writes:
On Tuesday, 7 November 2017 at 13:43:20 UTC, user1234 wrote:
 On Monday, 6 November 2017 at 20:14:17 UTC, Meta wrote:
 [...]
 import std.stdio;
 writeln(safeDeref(tree).right.right.val.orElse(-1));
 writeln(safeDeref(tree).left.right.left.right.orElse(null));
 writeln(safeDeref(tree).left.right.left.right.val.orElse(-1));

 vs.

 writeln(tree?. right?.right?.val ?: -1);
 writeln(tree?.left?.right?.left?.right);
 writeln(tree?.left?.right?.left?.right?.val ?: -1);

 The functionality is probably a good idea, but a library 
 solution is doable today without any acrobatics.
Show me a library solution that works fine with IDE completion (so for the safe navigation operator, not the Elvis one).
Yes, this is unfortunately the one sticking point of a library solution, although if the front end becomes fully usable as a library it may be possible to an extent.
Nov 07 2017
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 7 November 2017 at 13:43:20 UTC, user1234 wrote:
 On Monday, 6 November 2017 at 20:14:17 UTC, Meta wrote:
 The functionality is probably a good idea, but a library 
 solution is doable today without any acrobatics.
Show me a library solution that works fine with IDE completion (so for the safe navigation operator, not the Elvis one).
Well, the IDE can know when a particular standard library symbol is being used. It can detect this case and provide special autocompletion suggestions for it. Yes, this is not perfect. But where standard library symbols are commonly used, it is a workable solution.
Nov 13 2017
prev sibling next sibling parent reply Michael <michael toohuman.io> writes:
I can't quite see why this proposal is such a big deal to people 
- as has been restated, it's just a quick change in the parser 
for a slight contraction in the code, and nothing 
language-breaking, it's not a big change to the language at all.

On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 I am all for the Elvis operator, however I have two 
 reservations about it. The first is that I don't see much use 
 for it without a null-conditional. The second is that the 
 current proposed syntax ?: is MUCH to easily confused with ?.

 This is not easy to read: obj1?.obj2?.prop3?:constant.

 When designing syntax sugar, ergonomics are very important, 
 otherwise people won't use it. Microsoft spent a LOT of time 
 and treasure to learn these lessons for us. I see no reason to 
 ignore them just because "we don't like Microsoft"

 My proposal would be to copy what MSFT did, expect that I would 
 I would introduce both operators at the same time.

 Syntax as follows: obj1?.obj2?.prop3 ?? constant

 In practice I don't see much use of the idiom outside of 
 null's. The ONLY other thing that would work there is a boolean 
 field and you might as well just return the boolean itself 
 because the return values have to match types.
I feel this is kind of embellished somewhat. When you write
 This is not easy to read: obj1?.obj2?.prop3?:constant.
you're not separating it out as you do when you write your preferred version:
 Syntax as follows: obj1?.obj2?.prop3 ?? constant
How is
 obj1?.obj2?.prop3 ?: constant
not as easy to read as
 obj1?.obj2?.prop3 ?? constant
to me they are the same in terms of readability, only with ?? you have greater chances of mistyping and adding a second ? in there somewhere, whereas the ?: is just a contraction of the current syntax, I really don't think it's that difficult, so I'm not sure what people's hang-ups are, but I don't think the argument that ?? is easier to read than ?: holds any weight here, because one *is* a change to the language, and the other is a change to the parser and a contraction of a standard convention.
Nov 06 2017
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 11/6/17 12:20, Michael wrote:
 I can't quite see why this proposal is such a big deal to people - as
 has been restated, it's just a quick change in the parser for a slight
 contraction in the code, and nothing language-breaking, it's not a big
 change to the language at all.

 On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 I am all for the Elvis operator, however I have two reservations about
 it. The first is that I don't see much use for it without a
 null-conditional. The second is that the current proposed syntax ?: is
 MUCH to easily confused with ?.

 This is not easy to read: obj1?.obj2?.prop3?:constant.

 When designing syntax sugar, ergonomics are very important, otherwise
 people won't use it. Microsoft spent a LOT of time and treasure to
 learn these lessons for us. I see no reason to ignore them just
 because "we don't like Microsoft"

 My proposal would be to copy what MSFT did, expect that I would I
 would introduce both operators at the same time.

 Syntax as follows: obj1?.obj2?.prop3 ?? constant

 In practice I don't see much use of the idiom outside of null's. The
 ONLY other thing that would work there is a boolean field and you
 might as well just return the boolean itself because the return values
 have to match types.
I feel this is kind of embellished somewhat. When you write
 This is not easy to read: obj1?.obj2?.prop3?:constant.
you're not separating it out as you do when you write your preferred version:
 Syntax as follows: obj1?.obj2?.prop3 ?? constant
How is
 obj1?.obj2?.prop3 ?: constant
not as easy to read as
 obj1?.obj2?.prop3 ?? constant
You're right, I didn't, that was intentional, because sometimes people write things like that. And it took a while for anyone to say anything about it. That is my point. But that's the thing. The ?? is significantly more obvious in the condensed version. This is something that a UX designer would recognize instantly, but human factors are very definitely not our strong skill as engineers. FWIW, my human factors experience comes from the deep study of airline crashes that I do as a pilot.
 to me they are the same in terms of readability, only with ?? you have
 greater chances of mistyping and adding a second ? in there somewhere,
 whereas the ?: is just a contraction of the current syntax, I really
 don't think it's that difficult, so I'm not sure what people's hang-ups
 are, but I don't think the argument that ?? is easier to read than ?:
 holds any weight here, because one *is* a change to the language, and
 the other is a change to the parser and a contraction of a standard
 convention.
Two things. ?: is ALSO a change a to language (lexer+parser). As to the whole "it's no more likely to typo the colon than the question" argument, sure, but that depends on the keyboard layout more than anything else, what works for you may not work elsewhere. And in either case, it's an easy compiler error. So you don't win anything with the ?:, but you win readability with the ??. MSFT spends a LOT of time studying these things. It would be wise to learn for free from the money they spent. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Nov 09 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be 
 wise to learn for free from the money they spent.
Is that the same company that made Windows 10?
Nov 10 2017
next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 11/10/17 00:24, codephantom wrote:
 On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be wise to
 learn for free from the money they spent.
Is that the same company that made Windows 10?
And what? -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Nov 10 2017
parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 10:24:01 UTC, Adam Wilson wrote:
 And what?
This Windows 10. https://www.youtube.com/watch?v=KHG6fXEba0A You want us to look the MSFT on how things should be done??
Nov 10 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 10, 2017 10:36:01 codephantom via Digitalmars-d wrote:
 On Friday, 10 November 2017 at 10:24:01 UTC, Adam Wilson wrote:
 And what?
This Windows 10. https://www.youtube.com/watch?v=KHG6fXEba0A You want us to look the MSFT on how things should be done??
In general, I don't like Microsoft, and I certainly don't like what they've done with Windows post Windows 7, but that doesn't mean that everything they say or do is terrible. Even if some what they do is terrible, there are some really smart people working there, and some of what comes out of there is definitely good. I really don't think that judging the situation with ?: or ?? or any other operator in C# on what's happened with Windows 10 makes any sense. Sure, we're talking about the same company, but we're talking about completely different teams here. And Adam is talking about the research that they've done on the operators in C#, which is completely different from talking about what they've done with a product unrelated to that research. Shooting down an idea just because it comes from Microsoft (or any other company) rather than judging it on its technical merits is just bad policy. Ideas should be judged based on their own merit, not simply on where they came from. Based on other posts that you've made, you seem interested in bashing anything related to Windows or Microsoft, and that really isn't productive when we're trying to have a technical discussion. - Jonathan M Davis
Nov 10 2017
next sibling parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 10:51:28 UTC, Jonathan M Davis 
wrote:
merit, not simply on where they came from.
 Based on other posts that you've made, you seem interested in 
 bashing anything related to Windows or Microsoft, and that 
 really isn't productive when we're trying to have a technical 
 discussion.

 - Jonathan M Davis
yeah..whatever... maybe try getting a sense of humour..then the discussion might be interesting for a change.
Nov 10 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 10:51:28 UTC, Jonathan M Davis 
wrote:
 Shooting down an idea just because it comes from Microsoft (or 
 any other company) rather than judging it on its technical 
 merits is just bad policy. Ideas should be judged based on 
 their own merit, not simply on where they came from.

 Based on other posts that you've made, you seem interested in 
 bashing anything related to Windows or Microsoft, and that 
 really isn't productive when we're trying to have a technical 
 discussion.

 - Jonathan M Davis
and btw. the suggestion that we look to MSFT for how to do things with the D language, deserves (in my opinion), to be treated with humour. You disagree? Too bad.
Nov 10 2017
prev sibling next sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 10:51:28 UTC, Jonathan M Davis 
wrote:
 we're trying to have a technical discussion.

 - Jonathan M Davis
And will someone please tell me, where is technical benefit of putting this crap (?: or ??) into a programming language? After 8 pages of people rambling on about it, nobody agrees on anything. And then you have a go at me for trying to bring in some humour? Wow!
Nov 10 2017
parent reply Satoshi <satoshi rikarin.org> writes:
On Friday, 10 November 2017 at 11:12:38 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 10:51:28 UTC, Jonathan M Davis 
 wrote:
 we're trying to have a technical discussion.

 - Jonathan M Davis
And will someone please tell me, where is technical benefit of putting this crap (?: or ??) into a programming language? After 8 pages of people rambling on about it, nobody agrees on anything. And then you have a go at me for trying to bring in some humour? Wow!
"Technical benefit" Where is the technical benefit in changing design of web pages or apps? Why windows, Unity, KDE, Gnome or OSX changes their design by ages? Not everything is about technical benefits. Sometimes it's about better look, better usability or just innovation and bringing something new. You are judging C#, but looks where is D and where is C#.
Nov 10 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 11:19:39 UTC, Satoshi wrote:
 You are judging C#
Umm... I have 17y in C# programming. Was one of the first to take it up. Have designed/developed apps for large corporates. Yet, I switched from C# to D. I don't think looking to MSFT for programming language advice is a good idea. D is not C#. If someone doesn't agree with me, ok, let them argue their case, not try to silence me.
 but looks where is D and where is C#.
ok..and where exactly is C#? Still, to this day, trying to get itself out of the Windows only world. What a joke. The world moved beyond the Windows monopoly a decade ago. C# is still catching up..
Nov 10 2017
parent reply Satoshi <satoshi rikarin.org> writes:
On Friday, 10 November 2017 at 11:26:41 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 11:19:39 UTC, Satoshi wrote:
 You are judging C#
Umm... I have 17y in C# programming. Was one of the first to take it up. Have designed/developed apps for large corporates.
Umm... My old colleague had 30 years of development skills, he had developing apps for military sector and still he had writing 2000 lines long functions in C with memcpy and str* crap...
 Yet, I switched from C# to D.
I switched from D to C#. There aren't any positions for D.
 I don't think looking to MSFT for programming language advice 
 is a good idea. D is not C#. If someone doesn't agree with me, 
 ok, let them argue their case, not try to silence me.
Nobody is trying to silent you, you just started trolling there.
 but looks where is D and where is C#.
ok..and where exactly is C#? Still, to this day, trying to get itself out of the Windows only world. What a joke. The world moved beyond the Windows monopoly a decade ago. C# is still catching up..
How many corporations is using D right now? 10? Windows is still dominant OS and there are a lot of job opportunities for C#. D is unusable for startups or corporations where are junior programmers hired anyway because it's too complicated to use. And pay senior developers for job what can be done by juniors but in different language is not worth. (e.g. metaprogramming is great stuff but require high skilled programmers to use it correctly.)
Nov 10 2017
next sibling parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 11:45:25 UTC, Satoshi wrote:
 Nobody is trying to silent you, you just started trolling there.
Bullshit! I tried to inject some humour into the discussion. I thought that was pretty self-evident. The MSFT fanboys on these forums, which seem to completely lack any sense of humour, decided to take it personally.
Nov 10 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 11:45:25 UTC, Satoshi wrote:
 How many corporations is using D right now? 10?
 Windows is still dominant OS and there are a lot of job 
 opportunities for C#.

 D is unusable for startups or corporations where are junior 
 programmers hired anyway because it's too complicated to use. 
 And pay senior developers for job what can be done by juniors 
 but in different language is not worth.
 (e.g. metaprogramming is great stuff but require high skilled 
 programmers to use it correctly.)
Yeah..let's use the D forums to bag D. What a great idea. And, why are you trying to compare the state of C# to D. I really do not see your point. Besides being completely different languages, with completely different purposes, one is backed by a billion$ corporation, and the other is developed by a group of volunteers. I cannot accept the assertion by some, that we 'should' look to C# for language advice.
Nov 10 2017
parent reply Satoshi <satoshi rikarin.org> writes:
On Friday, 10 November 2017 at 12:06:42 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 11:45:25 UTC, Satoshi wrote:
 How many corporations is using D right now? 10?
 Windows is still dominant OS and there are a lot of job 
 opportunities for C#.

 D is unusable for startups or corporations where are junior 
 programmers hired anyway because it's too complicated to use. 
 And pay senior developers for job what can be done by juniors 
 but in different language is not worth.
 (e.g. metaprogramming is great stuff but require high skilled 
 programmers to use it correctly.)
Yeah..let's use the D forums to bag D. What a great idea.
Yeah, because my opinion about D will be more valuable for the language at C# forum :) I'm not bagging D I'm just providing my personal opinions, experience and expectations.
 And, why are you trying to compare the state of C# to D.

 I really do not see your point.

 Besides being completely different languages, with completely 
 different purposes, one is backed by a billion$ corporation, 
 and the other is developed by a group of volunteers.

 I cannot accept the assertion by some, that we 'should' look to 
 C# for language advice.
I'm comparing C# to D because D is trying to do the same stuff as C#. GUI development and website development. I used vibe.d, I used ASP.NET core and I'm still missing some C# features in D. So I'm sharing my experience and expectations. If you don't want to compare D with C# or other languages, just don't push D to the same place as C# is. Why isn't D standing as a replacement for C++ but pushing into webdev and gui dev? C++ is not used for webdev too, and gui dev in C++ is horrible. And yeah, swift was developed by some volunteers until Apple took it. Why Apple didn't take D instead?
Nov 10 2017
parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 12:23:06 UTC, Satoshi wrote:
 I'm comparing C# to D because D is trying to do the same stuff 
 as C#. GUI development and website development. I used vibe.d, 
 I used ASP.NET core and I'm still missing some C# features in 
 D. So I'm sharing my experience and expectations.

 If you don't want to compare D with C# or other languages, just 
 don't push D to the same place as C# is. Why isn't D standing 
 as a replacement for C++ but pushing into webdev and gui dev? 
 C++ is not used for webdev too, and gui dev in C++ is horrible.

 And yeah, swift was developed by some volunteers until Apple 
 took it. Why Apple didn't take D instead?
Well, I really don't want to argue with you, and I'm not sure we really have much to argue anyway. But I don't see D as a replacement for C#. C# has a hold of its territory pretty well, I don't see D intruding into it, any time soon. It certainly has some good feature that D could consider incorporating. I don't think (personally) the Elvis operator is one of them. Other disagree find. I'm with disagreement. C++ on the otherhand, is certainly where D can showcase it's benefit - and indeed where many focus their attention when it comes to marketing D. And if you had good skill in C++, and switched to D, and was good at D too, then you'll be part of the generation that will replace the C++ language and the C++ programmers ;-) Sorry to the C++ fanboys..if you're listening...don't take it personally.
Nov 10 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 11:19:39 UTC, Satoshi wrote:
 You are judging C#, but looks where is D and where is C#.
Where is C#? - good luck porting it to other (non MS, non .NET environments). - performance of large code bases can often be sluggish - VS.NET does most of the coding for you. - most C# developers have no idea what's being done behind the scenes. - you can't create a function outside of a class (great design decision btw!) I could go on..and on... It's had good sides and bad sides. MSFT fanboys are unable to distinguish the difference, and think everything must be great, cause MSFT/C# did it. MSFT have spent the last 7 years mostly adding useless stuff to C# - but like their design descions about Windows, and their other products. Instead of real innovation, we just get more useless stuff. These forums need more critical thinking, and better justification for new features (other than 'cause MSFT knows best'), or ('cause the language I'm used to using has it').
Nov 10 2017
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 10 November 2017 at 23:14:50 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 11:19:39 UTC, Satoshi wrote:
 You are judging C#, but looks where is D and where is C#.
Where is C#?
A supported and very popular language. Seriously in it the top ten popular language list for a good reason. You should google it.
 - good luck porting it to other (non MS, non .NET environments).
https://en.wikipedia.org/wiki/Mono_(software)
 - performance of large code bases can often be sluggish
Examples?
 - VS.NET does most of the coding for you.
https://en.wikipedia.org/wiki/Just-in-time_compilation
 - most C# developers have no idea what's being done behind the 
 scenes.
Neither do the majority of developers when it comes to their compilers.
 - you can't create a function outside of a class (great design 
 decision btw!)
That why C# have static classes. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-classes-and-static-class-members Not every programming language in existence needed to be Procedural based Language. You need to expand your horizons when it comes to different types of languages.
 These forums need more critical thinking, and better 
 justification for new features (other than 'cause MSFT knows 
 best'), or ('cause the language I'm used to using has it').
You should take your own advice first, when you insult other people by calling them "Microsoft fanboys". Take your snark somewhere else.
Nov 10 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy wrote:
 A supported and very popular language. Seriously in it the top 
 ten popular language list for a good reason. You should google 
 it.
I don't have to google it. I've been using it for 17 years.
 - VS.NET does most of the coding for you.
 https://en.wikipedia.org/wiki/Just-in-time_compilation
Won't be long till they do it ALL for you.
 Neither do the majority of developers when it comes to their 
 compilers.
Do most C# programmers even know what a compiler is? When was the last time a C# programmer actually compiled anything... I mean really...they just push button and have no idea whats going on.
 That why C# have static classes.
 https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-classes-and-static-class-members
 Not every programming language in existence needed to be 
 Procedural based Language. You need to expand your horizons 
 when it comes to different types of languages.
Can't take the criticism of C#? And your telling me to expand my horizons.. Hahhhaaa..... Just another MSFT fanboy..gee..their really coming out now...
Nov 10 2017
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 11 November 2017 at 02:30:50 UTC, codephantom wrote:
 On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy 
 wrote:
 A supported and very popular language. Seriously in it the top 
 ten popular language list for a good reason. You should google 
 it.
I don't have to google it. I've been using it for 17 years.
Then you should know the current status of it and how it compare it to D.
 - VS.NET does most of the coding for you.
 https://en.wikipedia.org/wiki/Just-in-time_compilation
Won't be long till they do it ALL for you.
You not making any sense here. Every programming language comes with their standard libraries, so that programmers won't reinvent the wheel every time they program.
 Neither do the majority of developers when it comes to their 
 compilers.
Do most C# programmers even know what a compiler is? When was the last time a C# programmer actually compiled anything... I mean really...they just push button and have no idea whats going on.
It called "Roslyn", and you can google the information. LOL at your "actually compiled anything"! Really? Do you even understand what Just-in-time compilation even means!? It like you didn't read the link that I posted to you! Do your think you antidote experience applies to every c# programmer out there?
 That why C# have static classes.
 https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-classes-and-static-class-members
 Not every programming language in existence needed to be 
 Procedural based Language. You need to expand your horizons 
 when it comes to different types of languages.
 Can't take the criticism of C#?
It not that I can't take criticism, is that your criticism doesn't make any sense. That like criticizing Prolog for not having any procedural base language when it designed to be a purely logic programming language.
Nov 11 2017
prev sibling next sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy wrote:
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
I'm just dishing out what they've been doing to me, simply cause I dared to critcise something that MSFT produce. You take your snark elsewhere!
Nov 10 2017
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 11 November 2017 at 02:34:11 UTC, codephantom wrote:
 On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy 
 wrote:
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
I'm just dishing out what they've been doing to me, simply cause I dared to critcise something that MSFT produce. You take your snark elsewhere!
The fact that you not once, not twice, but three times you reply to the same statement! Wow I must really got underneath your skin when I say that.
Nov 11 2017
parent codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 16:45:11 UTC, 12345swordy wrote:
 On Saturday, 11 November 2017 at 02:34:11 UTC, codephantom 
 wrote:
 On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy 
 wrote:
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
I'm just dishing out what they've been doing to me, simply cause I dared to critcise something that MSFT produce. You take your snark elsewhere!
The fact that you not once, not twice, but three times you reply to the same statement! Wow I must really got underneath your skin when I say that.
Well, that was your purpose.. wasn't it. It is afterall, the moda operandi of MSFT fanboys. Thanks for your contribution.
Nov 11 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy wrote:
 best'), or ('cause the language I'm used to using has it').
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
Any opinion/idea offered by someone who can't take criticism of MSFT products, is not worth very much to me. As far as I'm concerned, it demonstrates a closed mind, incapable of exploring alternative solutions. It invites suspicion. Now...if you're not actually a 'MSFT fanboy', then i dare you to post a link that criticises the C# langauge, or any other MSFT product.
Nov 10 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy wrote:
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
and btw. if you had gone back a few threads (instead of just jumping into a conversation to just have a go at me), then you'd know that it all started because i attempted to inject some humour into the converstation, and used a youtube video that made fun of the design of Windows 10 - in a humerous manner. What results from that, was some guy telling me that I was bashing on Adam. That i was anti this and anti that. Then others got involved too, trying to bash on me even further. The same thing happened when I mentioned my concern that 64bit D on Windows can only happen if the user is prepared to download GB's of propriatory, closed source, bloatware. When I did that, MSFT fanboys came out to dump on me, instead of saying..yeah..perhaps that might be a good way for D to proceed. So, if you're all willing to dish it out to me, you better be prepared to take some too! D's future will depend not on how well it ties into a propriatory o/s, but who well it runs in open source environments. Anyone who doesn't see that, doesn't understand whats going on in the world of software development. Even MSFT get that, and are now trying to port C# as quickly as possibly to other platforms to hold off the competition that's already here, and more to come. I think D is where it is, because it was developed on Windows (windows 32 bit it seems). Had it been developed on an open source operating system, I expect it would be miles ahead of where it currently is. If D is making Windows its platform priority, then it has to compete with exiting MSFT solutions on the platform, which in my mind, are far superior to anyting D can or will be able to provide. D should focus its attention elsewhere. That's just my opinion. Others can disagree. I don't mind disagreement. But I mind not being allowed to disagree!
Nov 10 2017
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 11 November 2017 at 03:49:24 UTC, codephantom wrote:
 On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy 
 wrote:
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
and btw. if you had gone back a few threads (instead of just jumping into a conversation to just have a go at me), then you'd know that it all started because i attempted to inject some humour into the converstation, and used a youtube video that made fun of the design of Windows 10 - in a humerous manner. What results from that, was some guy telling me that I was bashing on Adam. That i was anti this and anti that. Then others got involved too, trying to bash on me even further. The same thing happened when I mentioned my concern that 64bit D on Windows can only happen if the user is prepared to download GB's of propriatory, closed source, bloatware. When I did that, MSFT fanboys came out to dump on me, instead of saying..yeah..perhaps that might be a good way for D to proceed. So, if you're all willing to dish it out to me, you better be prepared to take some too! D's future will depend not on how well it ties into a propriatory o/s, but who well it runs in open source environments. Anyone who doesn't see that, doesn't understand whats going on in the world of software development. Even MSFT get that, and are now trying to port C# as quickly as possibly to other platforms to hold off the competition that's already here, and more to come. I think D is where it is, because it was developed on Windows (windows 32 bit it seems). Had it been developed on an open source operating system, I expect it would be miles ahead of where it currently is. If D is making Windows its platform priority, then it has to compete with exiting MSFT solutions on the platform, which in my mind, are far superior to anyting D can or will be able to provide. D should focus its attention elsewhere. That's just my opinion. Others can disagree. I don't mind disagreement. But I mind not being allowed to disagree!
Indeed, the strength of D is that it is portable among the big platforms remaining. One of its drawbacks can be seen somehow as an asset. Its lack of preferred GUI kit means that it is not intimately bound to the user interface of that platform. Swift and Objective-C are glued to Apple and outside of it are niche. Same for C# on Windows. Java is portable but is a bitch to distribute, especially on Windows where more often than not it poses security risks that IT departments do not like.
Nov 11 2017
parent reply codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 09:47:32 UTC, Patrick Schluter 
wrote:
 Indeed, the strength of D is that it is portable among the big 
 platforms remaining. One of its drawbacks can be seen somehow 
 as an asset. Its lack of preferred GUI kit means that it is not 
 intimately bound to the user interface of that platform. Swift 
 and Objective-C are glued to Apple and outside of it are niche. 
 Same for C# on Windows. Java is portable but is a bitch to 
 distribute, especially on Windows where more often than not it 
 poses security risks that IT departments do not like.
Yeah, integrating gui's into a programming language is complex....there are some gui kits for D in github, but none I find compelling at this stage - even though they're authors are doing a great job. It's not that it's too complex technically, but the corporates I've done work for would never allow you to bring in your own gui anyway. Everything has to be standardised, and look familiar to users. same with vibe.d - great idea, great implementation - but none of the corporates I've done work for are ever going to do anything with vibe.d - ever. Startups are a good potential market for D - but it still faces a lot of competition. I'd like D to think bigger than just duplicating what's out there, and being 'compatible' with this and that operating system - or just be marketed as a quicker way to compile your slow c++ code. I'd wouldn't mind seeing a new open source operating system, lets call it 'System D'....just slips of the tongue doesn't it ;-) (micro) Kernel : written in D Development tools: written in D Userland/Gui : written in D Webserver: written in D ... ..... ....... D is a systems programming language, and has the potential to do all of this, and more. Then let others look at D, instead of D looking to others. Of course, it's easy to have such a grand vision..... But I'm really struggling to see any compelling vision at the moment, other than D just being another language to choose from. The vision, based on what I've been reading on these forums, seems to be about 'grabbing stuff from this and that language, and integrating this and that feature, or this and that syntax' - as if all of this will make D more attractive out in the real world. I don't see that mindset leading anywhere. It will just lead to an even more complex language, with even more features. At that is the point where people start to envision something simpler and easier...and the cycle starts all over again... in 2030, Go will be so complex someone will have to invent GoLess. But, I'm happy nonetheless...cause I only program for recreation these days, and D provides a really nice playground for me, with lots of new toys to play with....and many are yet to be discovered. And most importantly, it runs on FreeBSD!
Nov 11 2017
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 11/11/2017 11:18 AM, codephantom wrote:
 On Saturday, 11 November 2017 at 09:47:32 UTC, Patrick Schluter wrote:
 Indeed, the strength of D is that it is portable among the big 
 platforms remaining. One of its drawbacks can be seen somehow as an 
 asset. Its lack of preferred GUI kit means that it is not intimately 
 bound to the user interface of that platform. Swift and Objective-C 
 are glued to Apple and outside of it are niche. Same for C# on 
 Windows. Java is portable but is a bitch to distribute, especially on 
 Windows where more often than not it poses security risks that IT 
 departments do not like.
Yeah, integrating gui's into a programming language is complex....there are some gui kits for D in github, but none I find compelling at this stage - even though they're authors are doing a great job. It's not that it's too complex technically, but the corporates I've done work for would never allow you to bring in your own gui anyway. Everything has to be standardised, and look familiar to users.
GUI toolkits are definitely complex. Everything from rendering of fonts correctly (bidi layouts) to accessibility (which is basically impossible to do right too) and that's with ignoring more obvious things like how to render a widget.
Nov 11 2017
prev sibling next sibling parent reply Satoshi <satoshi rikarin.org> writes:
On Saturday, 11 November 2017 at 11:18:24 UTC, codephantom wrote:
 I'd like D to think bigger than just duplicating what's out 
 there, and being 'compatible' with this and that operating 
 system
  - or just be marketed as a quicker way to compile your slow 
 c++ code.

 I'd wouldn't mind seeing a new open source operating system, 
 lets call it 'System D'....just slips of the tongue doesn't it 
 ;-)
Yeah, stop duplicating what's out there and start writing similar software what already exists. Sounds great.
Nov 11 2017
next sibling parent codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 12:53:46 UTC, Satoshi wrote:
 Yeah, stop duplicating what's out there and start writing 
 similar software what already exists. Sounds great.
Dude.. I can only assume you're very young. Why do you think C took off as it did? It wasn't because people spent hours on forums discussing how to integrate this operator, or that operator.
Nov 11 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 12:53:46 UTC, Satoshi wrote:
 Yeah, stop duplicating what's out there and start writing 
 similar software what already exists. Sounds great.
Where is the secure, modular operating system, written in a safe language? And a language that you can use for the rest of the o/s ecosystem too. People are still searching for this holy grail..it hasn't been found.. Why? Perhaps because the right language has come around yet. Maybe D is it, maybe not... ..so it actually *doesn't* already exist.
Nov 11 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 11 November 2017 at 12:53:46 UTC, Satoshi wrote:
 Yeah, stop duplicating what's out there and start writing 
 similar software what already exists. Sounds great.
And every man, women... and their 2 dogs...are targetting mobile, web, cloud these days. The idea that D is going to compete with the like of Google/Apple/MSFT in these areas..is..well..unconvincing. The idea that such companies and going to rip up their massive codebases and rewrite them in D...is..well..unconvincing. But everyone wants a more modular, more refined, more modern, more secure operating system ...and a more secure systems programming language. But very who's focused on that? Go has some potential, but I don't like many of its design decisions. Rust is going nowhere, IMHO. So D could take advantage of the fact the big corporates are focused elsewhere (and, also, that they're not very likely to turn their attention to redeveloping their os any time soon). It could take advantage of Go, having made some questionable design decisions. It could take advantage of Rust, seemingly going nowhere (IMHO). So if there was ever a time for 'System D', it's now. Instead, everyones focused on making it compatible..with this..and that...which is great..that will certainly bring attention to D...but I suspect it won't do too much more than that. D needs a grander vision.
Nov 11 2017
parent Satoshi <satoshi rikarin.org> writes:
On Sunday, 12 November 2017 at 03:25:47 UTC, codephantom wrote:
 But everyone wants a more modular, more refined, more modern, 
 more secure operating system ...and a more secure systems 
 programming language.
How rewriting Linux from scratch will enhance security of the OS? By introducing more bugs to the new code?
 But very who's focused on that?

 Go has some potential, but I don't like many of its design 
 decisions.
fakin' D fanboy!
 So D could take advantage of the fact the big corporates are 
 focused elsewhere (and, also, that they're not very likely to 
 turn their attention to redeveloping their os any time soon).
Because nobody spends billions of dollars on something what will not brings anything new.
 It could take advantage of Go, having made some questionable 
 design decisions.

 It could take advantage of Rust, seemingly going nowhere (IMHO).

 So if there was ever a time for 'System D', it's now.

 Instead, everyones focused on making it compatible..with 
 this..and that...which is great..that will certainly bring 
 attention to D...but I suspect it won't do too much more than 
 that.

 D needs a grander vision.
Nov 12 2017
prev sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 11 November 2017 at 11:18:24 UTC, codephantom wrote:
 Yeah, integrating gui's into a programming language is 
 complex....there are some gui kits for D in github, but none I 
 find compelling at this stage - even though they're authors are 
 doing a great job.

 It's not that it's too complex technically, but the corporates 
 I've done work for would never allow you to bring in your own 
 gui anyway. Everything has to be standardised, and look 
 familiar to users.
If you target windows and you do not mind to install a free version of Delphi on your pc, you can use the Delphi VCL/Firemonkey gui toolkit, create your ui forms in the Delphi editor while implementing the program logic in D. https://forum.dlang.org/thread/fwsbrmkbqkolrsztxcoq forum.dlang.org Kind regards Andre
Nov 11 2017
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Friday, 10 November 2017 at 23:14:50 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 11:19:39 UTC, Satoshi wrote:
 You are judging C#, but looks where is D and where is C#.
Where is C#?
In about 50% of the corporations doing enterprise programming.
 - good luck porting it to other (non MS, non .NET environments).
.NET Core is getting there.
 - performance of large code bases can often be sluggish
What's your proof of this? I have worked with multiple large code bases written in .NET without bad performance?
 - VS.NET does most of the coding for you.
Uh, what? Because of JIT? Okay. Then "D" does most of the coding for you too then, since you're not writing the assembly code nor are you manually linking your object files.
 - most C# developers have no idea what's being done behind the 
 scenes.
To me, it seems like you have no idea what's being done behind the scenes.
 - you can't create a function outside of a class (great design 
 decision btw!)
Different language, different design choice, different goals. It's not like every decision in D are the best either. Every language has their flaws.
 I could go on..and on...
Yeah, but I'd rather if you didn't.
 It's had good sides and bad sides.

 MSFT fanboys are unable to distinguish the difference, and 
 think everything must be great, cause MSFT/C# did it.
I'm not even a "MSFT" fanboy. I replaced all my private .NET code with D, but not because I despise .NET at all, but because D is my preferred language of choice. There are certain areas of .NET that D could learn a lot from.
 MSFT have spent the last 7 years mostly adding useless stuff to 
 C# - but like their design descions about Windows, and their 
 other products. Instead of real innovation, we just get more 
 useless stuff.
Different people, different opinions.
 These forums need more critical thinking, and better 
 justification for new features (other than 'cause MSFT knows 
 best'), or ('cause the language I'm used to using has it').
If I got a dollar for every time you said "MSFT", I'd be able to buy Microsoft. --------------- On Saturday, 11 November 2017 at 02:52:47 UTC, codephantom wrote:
 On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy 
 wrote:
 best'), or ('cause the language I'm used to using has it').
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
Any opinion/idea offered by someone who can't take criticism of MSFT products, is not worth very much to me. As far as I'm concerned, it demonstrates a closed mind, incapable of exploring alternative solutions. It invites suspicion.
Opinions without facts are pretty useless. Something you should be familiar with.
 Now...if you're not actually a 'MSFT fanboy', then i dare you 
 to post a link that criticises the C# langauge, or any other 
 MSFT product.
Why would anyone waste their time finding that? It's such a petty thing. It's like saying: "If you're not a fan of Justin Bieber, I dare you to find an article that dislikes him." I thought we were more professional on these forums, but I guess kindergarten is all around the internet. ------------------------- On Saturday, 11 November 2017 at 03:49:24 UTC, codephantom wrote:
 On Saturday, 11 November 2017 at 01:37:01 UTC, 12345swordy 
 wrote:
 You should take your own advice first, when you insult other 
 people by calling them "Microsoft fanboys". Take your snark 
 somewhere else.
and btw. if you had gone back a few threads (instead of just jumping into a conversation to just have a go at me), then you'd know that it all started because i attempted to inject some humour into the converstation, and used a youtube video that made fun of the design of Windows 10 - in a humerous manner.
Hahahah so funny....... no.
 What results from that, was some guy telling me that I was 
 bashing on Adam. That i was anti this and anti that.

 Then others got involved too, trying to bash on me even further.
Nobody is "bashing" anyone.
 So, if you're all willing to dish it out to me, you better be 
 prepared to take some too!
Such a mature thing to do.
 D's future will depend not on how well it ties into a 
 propriatory o/s, but who well it runs in open source 
 environments. Anyone who doesn't see that, doesn't understand 
 whats going on in the world of software development. Even MSFT 
 get that, and are now trying to port C# as quickly as possibly 
 to other platforms to hold off the competition that's already 
 here, and more to come.
And your source of information is?
 I think D is where it is, because it was developed on Windows 
 (windows 32 bit it seems). Had it been developed on an open 
 source operating system, I expect it would be miles ahead of 
 where it currently is.
I'm not even sure what you're referring to in terms of D's issues. Especially when you mention that you think it was developed on Windows. Isn't it strange Windows the OS left out mostly by D then? What you say doesn't match up with any facts around here. In fact the only OS that is currently troublesome with D is iOS as far as I'm aware.
 If D is making Windows its platform priority, then it has to 
 compete with exiting MSFT solutions on the platform, which in 
 my mind, are far superior to anyting D can or will be able to 
 provide. D should focus its attention elsewhere.
It's not about winning a competition. ------------------ On Saturday, 11 November 2017 at 04:55:15 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be 
 wise to learn for free from the money they spent.
This is valid MSFT code, I believe: A?.B?.C?[0] ?? E A?.B?.C?[0] == E I have been coding on and off, since 1992, in various languages. So can you please tell what this code means? Can you please tell me what it was that MSFT learnt (and spent money to do so), so as to enable coders to write such code?
Every operator in every language can be abused. Every language has good and bad programmers. In fact without the null-conditional operator the code would look even worse. Ex. D equivalent: A ? A.B ? A.B.C ? A.B.C[0] : E : E : E (A ? A.B ? A.B.C ? A.B.C[0] : null : null : null) == E -------------------------------- On Saturday, 11 November 2017 at 05:20:39 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be 
 wise to learn for free from the money they spent.
I just saw this about the new 'damnit' operator, for C# 8. https://github.com/dotnet/csharplang/issues/556 I thought it was a joke at first, but they are serious. C# seem to becoming language of operators. ool? a, b; ... var x = !a! != b! ? a! : !b!; Yeah...lets follow there example...they seem to know better.
It's a proposal, not an actually accepted implementation. ----------- I'm tired so I will end my post here.
Nov 11 2017
next sibling parent codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 01:00:46 UTC, bauss wrote:
 I'm tired so I will end my post here.
Great contribution btw. I might actually read it when i have nothing else to do...which will be a long way off...
Nov 11 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 01:00:46 UTC, bauss wrote:
 and btw. if you had gone back a few threads (instead of just 
 jumping into a conversation to just have a go at me), then 
 you'd know that it all started because i attempted to inject 
 some humour into the converstation, and used a youtube video 
 that made fun of the design of Windows 10 - in a humerous 
 manner.
Hahahah so funny....... no.
Seriously? You didn't find this video funny? https://www.youtube.com/watch?v=KHG6fXEba0A I think you've clearly demonstrated why I felt compelled to use the word 'fanboy'. Microsoft fanboys hate anyone who: - Uses Linux - Rightfully criticizes Microsoft on some of their faults - Dares to pose a different opinion
Nov 11 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 01:00:46 UTC, bauss wrote:
 and btw. if you had gone back a few threads (instead of just 
 jumping into a conversation to just have a go at me), then 
 you'd know that it all started because i attempted to inject 
 some humour into the converstation, and used a youtube video 
 that made fun of the design of Windows 10 - in a humerous 
 manner.
Hahahah so funny....... no.
And again, I'd like to point out to everyone, that the attack on me, in this thread, started becasue I dared to poke fun at the design of Windows 10. In another discussion, the attack on me started because i dared to suggest you should be able to compile a 64bit D executable, on Windows, without have to download GB's of propriatey, closed-source, bloatware. That really seemed to pee of the MSFT fanboys on these forums...who then thought it was appropriate to start attacking me personally. I don't mind dishing it out back to them...if they persist.
Nov 11 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 01:00:46 UTC, bauss wrote:
 On Saturday, 11 November 2017 at 05:20:39 UTC, codephantom 
 wrote:
 On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be 
 wise to learn for free from the money they spent.
I just saw this about the new 'damnit' operator, for C# 8. https://github.com/dotnet/csharplang/issues/556 I thought it was a joke at first, but they are serious. C# seem to becoming language of operators. ool? a, b; ... var x = !a! != b! ? a! : !b!; Yeah...lets follow there example...they seem to know better.
It's a proposal, not an actually accepted implementation.
It's more than a proposal. Mad Torgersen (i.e. mean, Mads Torgersen)...is actually pursuing its integration into C# 8 .... https://channel9.msdn.com/Blogs/Seth-Juarez/A-Preview-of-C-8-with-Mads-Torgersen 15m:08s ...the 'I know better' operator (aks damnit operator) I wonder if you'll have to upgrade your Visual Studio to the next version though...before you can use it...or maybe your .NET version will need upgrading..or maybe the .NET won't work on Win7..or maybe the new VS won't work in Windows 7....of maybe they'll release Windows 12, and only make C# 8 available on that platform....
Nov 11 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 01:00:46 UTC, bauss wrote:
 I'm tired so I will end my post here.
And I'm going to end all my posts here, cause I'm sick of arguing with MSFT fanboys, who want to restrain D's development by tying it into propriatery, closed source, bloatware. I'm going to start focusing my attention on rewriting (some) of FreeBSD userland, using D ..and see what happens. (btw. such programs can easily be migrated to Linux/OSX too...or the new 'System D' ..when it arrives ;-) Besides being more productive, it also seems like more fun, than responding to MSFT fanboys (although that's been fun too). Sorry MSFT fanboys, if you don't know what userland means. Go google it.
Nov 11 2017
next sibling parent reply Satoshi <satoshi rikarin.org> writes:
On Sunday, 12 November 2017 at 04:40:21 UTC, codephantom wrote:
 On Sunday, 12 November 2017 at 01:00:46 UTC, bauss wrote:
 I'm tired so I will end my post here.
And I'm going to end all my posts here, cause I'm sick of arguing with MSFT fanboys, who want to restrain D's development by tying it into propriatery, closed source, bloatware.
Yeah, I'm MSFT fanboy because I think ?? and ?. operators from C# are useful. Think of a number between 1 and 10.... Yes, that's your IQ.
 I'm going to start focusing my attention on rewriting (some) of 
 FreeBSD userland, using D ..and see what happens. (btw. such 
 programs can easily be migrated to Linux/OSX too...or the new 
 'System D' ..when it arrives ;-)
You should starts from Kernel. And if you don't want to start form scratch, you can use my OS written in D :) https://github.com/Rikarin/Trinix
 Besides being more productive, it also seems like more fun, 
 than responding to MSFT fanboys (although that's been fun too).
How is rewriting the same software from C to D productive?
 Sorry MSFT fanboys, if you don't know what userland means. Go 
 google it.
Yeah, nobody is as smart as you. Good luck with rewriting the same code. It's boring, bug introducing and useless work but do what you want.
Nov 12 2017
parent Satoshi <satoshi rikarin.org> writes:
On Sunday, 12 November 2017 at 08:33:34 UTC, Satoshi wrote:
 I'm going to start focusing my attention on rewriting (some) 
 of FreeBSD userland, using D ..and see what happens. (btw. 
 such programs can easily be migrated to Linux/OSX too...or the 
 new 'System D' ..when it arrives ;-)
You should starts from Kernel. And if you don't want to start form scratch, you can use my OS written in D :) https://github.com/Rikarin/Trinix
I'm expecting your first pull request in couple of days :)
Nov 12 2017
prev sibling next sibling parent reply Satoshi <satoshi rikarin.org> writes:
It's for you!

https://i.imgur.com/NNgrSyP.png
Nov 12 2017
parent codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 08:59:05 UTC, Satoshi wrote:
 It's for you!

 https://i.imgur.com/NNgrSyP.png
If you're actually taking bets on that...then put me down for $10_000.00 on the MSFT fanbois that is ;-) Nice stuff with Trinix. I'll cross you off my list of fanboys...for now.
Nov 12 2017
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 12 November 2017 at 04:40:21 UTC, codephantom wrote:
 On Sunday, 12 November 2017 at 01:00:46 UTC, bauss wrote:
 I'm tired so I will end my post here.
And I'm going to end all my posts here, cause I'm sick of arguing with MSFT fanboys, who want to restrain D's development by tying it into propriatery, closed source, bloatware. Besides being more productive, it also seems like more fun, than responding to MSFT fanboys (although that's been fun too).
I told you once and I'll tell you twice. I'm definitely not a MSFT fan boy. If I were one, I wouldn't have written a whole framework to replace my ASP.NET projects with D. I would probably have .NET languges installed too, which I don't. The only thing I have in my development environment that's related to MS is their linker from Visual Studio, but I don't have anything else installed from VS. For the simply fact, I don't write any .NET code privately. I have some projects I still maintain, but I can do that without VS. All projects I have that I currently work on are written in D or C. ----- On Sunday, 12 November 2017 at 08:59:05 UTC, Satoshi wrote:
 It's for you!

 https://i.imgur.com/NNgrSyP.png
Laughed really hard.
Nov 12 2017
next sibling parent codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 16:47:02 UTC, bauss wrote:
 I told you once and I'll tell you twice.

 I'm definitely not a MSFT fan boy.
Well, you were pretty quick to jump into the middle of a conversation, just to have a long..drawn out....go at me, because I had some critical comments to say about C# - a language which I know all to well. Only a MSFT fanboy would defend C# with that level of passion. What else am I meant to assume?
Nov 12 2017
prev sibling parent codephantom <me noyb.com> writes:
On Sunday, 12 November 2017 at 16:47:02 UTC, bauss wrote:
 I told you once and I'll tell you twice.

 I'm definitely not a MSFT fan boy.

 The only thing I have in my development environment that's 
 related to MS is their linker from Visual Studio, but I don't 
 have anything else installed from VS.

 All projects I have that I currently work on are written in D 
 or C.
ok..I'll take you off the list too..for now. I think maybe I need to get a cute gravatar, like you and Satoshi. Maybe a little kitten or something. Then maybe people will be less eager to attack me....
Nov 12 2017
prev sibling next sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 10:51:28 UTC, Jonathan M Davis 
wrote:
 Shooting down an idea just because it comes from Microsoft (or 
 any other company) rather than judging it on its technical 
 merits is just bad policy. Ideas should be judged based on 
 their own merit, not simply on where they came from.


 - Jonathan M Davis
Can I remind you, of one of your great contribtions to this discussion: "So, I really don't think that there's any point in adding the Elvis operator, but there are some folks here who seem to think that it's a great loss that we don't have it, because they're used to writing stuff like that in languages like C#, which do way more with classes and null than D code typically does." Any then you have a go at me, for saying we shouldn't be looking to C#? Wow!
Nov 10 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 10, 2017 11:39:48 codephantom via Digitalmars-d wrote:
 On Friday, 10 November 2017 at 10:51:28 UTC, Jonathan M Davis

 wrote:
 Shooting down an idea just because it comes from Microsoft (or
 any other company) rather than judging it on its technical
 merits is just bad policy. Ideas should be judged based on
 their own merit, not simply on where they came from.


 - Jonathan M Davis
Can I remind you, of one of your great contribtions to this discussion: "So, I really don't think that there's any point in adding the Elvis operator, but there are some folks here who seem to think that it's a great loss that we don't have it, because they're used to writing stuff like that in languages like C#, which do way more with classes and null than D code typically does." Any then you have a go at me, for saying we shouldn't be looking to C#? Wow!
I "had a go at you," because it seemed like you were bashing on Adam for suggesting that we look at what C# had done and what research Microsoft had done simply because it was Microsoft that had done it. You have been bashing on Microsoft in so many posts that there's no way that I'm going to be able to tell when you're trying to make a joke and when you're simply making fun of Microsoft and putting down information or an idea because it came from Microsoft. I don't think that the elvis operator and its ilk should be added to D, because I don't think that D is in the same position as C# (and as such, it's not useful in D in the same way), and I think that code that's written to use null in a way that would make heavy use of such operators desirable is code that is going about things in a bad way. Sometimes, it makes a lot of sense for a reference or pointer to be null (especially when it's declared), but I'm very much against code where many references or pointers in the program would be null without it being a bug. I think that that's just begging for bugs related to null. However, I see no problem with someone presenting information from Microsoft about C# and why they did what they did with their operators. That doesn't mean that I think that we should do what they did, but it's perfectly valid information to be used in support of getting new operators in D if that's what the person posting wants. And even if we don't want to take the same path in D, it can still better inform our decisions. - Jonathan M Davis
Nov 10 2017
parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 11:55:52 UTC, Jonathan M Davis 
wrote:
 I "had a go at you," because it seemed like you were bashing on 
 Adam for suggesting that we look at what C# had done and what 
 research Microsoft had done simply because it was Microsoft 
 that had done it. You have been bashing on Microsoft in so many 
 posts that there's no way that I'm going to be able to tell 
 when you're trying to make a joke and when you're simply making 
 fun of Microsoft and putting down information or an idea 
 because it came from Microsoft.

 - Jonathan M Davis
Well, you just got it wrong, and your comments were unfair, and actually, your comment were 'bashing' on me! I simply used a humourous youtube video, as a way to suggest that we reconsider whether we 'should' (as Adam puts it), take advice from MSFT. For that to be taken as 'bashing on Adam', is ridiculous. And to be honest, I find the MSFT fanboys on these forums always seem to react in that way, like MSFT is core part of their personality or something. You can't say anything negative about a MSFT product without them taking it personally, as though your directly insulted them. And then their mates decide to get involved too, and the whole thing just seems ridiculous. I had a go at Visual Studio, because it's ridiculous that D relies so much on it. Some don't agree - ok, but I got bashed on for that by the MSFT fanboys. Then I had a go at Windows 10, cause I tried to install it to use the Ubuntu shell to run D. But I could't even find how to do simple things in Windows 10. So please, give some proper 'context' when you next comment about me 'bashing on Microsoft'.
Nov 10 2017
parent reply Satoshi <satoshi rikarin.org> writes:
On Friday, 10 November 2017 at 12:27:22 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 11:55:52 UTC, Jonathan M Davis 
 wrote:
 [...]
Well, you just got it wrong, and your comments were unfair, and actually, your comment were 'bashing' on me! I simply used a humourous youtube video, as a way to suggest that we reconsider whether we 'should' (as Adam puts it), take advice from MSFT. For that to be taken as 'bashing on Adam', is ridiculous. And to be honest, I find the MSFT fanboys on these forums always seem to react in that way, like MSFT is core part of their personality or something. You can't say anything negative about a MSFT product without them taking it personally, as though your directly insulted them. And then their mates decide to get involved too, and the whole thing just seems ridiculous.
You didn't say anything negative about MSFT you just start making jokes about it. Then get rect and start crying and saying you did not troll. I'm not MSFT fanboy, I just find some of the C# features useful, nothing more.
 I had a go at Visual Studio, because it's ridiculous that D 
 relies so much on it. Some don't agree - ok, but I got bashed 
 on for that by the MSFT fanboys.

 Then I had a go at Windows 10, cause I tried to install it to 
 use the Ubuntu shell to run D. But I could't even find how to 
 do simple things in Windows 10.
99% of Windows users couldn't find how to do basic stuff in Linux but they are not blaming whole Linux community for it.
 So please, give some proper 'context' when you next comment 
 about me 'bashing on Microsoft'.
Nov 10 2017
next sibling parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 12:42:55 UTC, Satoshi wrote:
 You didn't say anything negative about MSFT you just start 
 making jokes about it.
ok. note taken. no jokes about msft allowed on D forums. got it. thanks for your input Satoshi.
Nov 10 2017
prev sibling next sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 12:42:55 UTC, Satoshi wrote:
 99% of Windows users couldn't find how to do basic stuff in 
 Linux ..
yeah.. imagine if I had said that...all hell would have broken loose.
Nov 10 2017
parent reply bauss <jj_1337 live.dk> writes:
On Friday, 10 November 2017 at 12:48:53 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 12:42:55 UTC, Satoshi wrote:
 99% of Windows users couldn't find how to do basic stuff in 
 Linux ..
yeah.. imagine if I had said that...all hell would have broken loose.
And 99% of Linux users don't know what the word convenience and user-friendly mean.
Nov 10 2017
parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 14:37:13 UTC, bauss wrote:
 On Friday, 10 November 2017 at 12:48:53 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 12:42:55 UTC, Satoshi wrote:
 99% of Windows users couldn't find how to do basic stuff in 
 Linux ..
yeah.. imagine if I had said that...all hell would have broken loose.
And 99% of Linux users don't know what the word convenience and user-friendly mean.
dude! why is that pointed at me? I was just repeating what someone else said, to demonstrate, that if i had said that, certain people on these forums would feel even more justified to have a go at me. I think you're just demonstrating my point...and I didn't even say it. I'm one of the few people on these forums, i expect, that quad boots into different operating system every day. I have almost everyone os in a virtual machine too. I like and prefer FreeBSD to them all, but I don't limit myself to it. I'm sick of MSFT fanboys on these forums having a got at me!
Nov 10 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 12:42:55 UTC, Satoshi wrote:
 You didn't say anything negative about MSFT you just start 
 making jokes about it.
 Then get rect and start crying and saying you did not troll.
 I'm not MSFT fanboy, I just find some of the C# features 
 useful, nothing more.
So making a joke about MSFT excuses you and others to start bashing on me? Really. That is more of a joke.
Nov 10 2017
parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 12:51:04 UTC, codephantom wrote:
 So making a joke about MSFT excuses you and others to start 
 bashing on me?

 Really. That is more of a joke.
ohh..anyone don't know what MSFT fanboy is? https://www.urbandictionary.com/define.php?term=Microsoft%20Fanboy
Nov 10 2017
prev sibling parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 10:51:28 UTC, Jonathan M Davis 
wrote:
 Based on other posts that you've made, you seem interested in 
 bashing anything related to Windows or Microsoft, and that 
 really isn't productive when we're trying to have a technical 
 discussion.

 - Jonathan M Davis
And I see you conveniently don't mention, that I posted on several discussion, that Windows XP is one of my favourite all time operating systems (yeah..made by Microsoft did you know?). And I see you conveniently don't mention, that I posted that I run Windows Mobile on my phone. That's why the only conclusions I can come to, is that MSFT fanboys runs these forums. FORUM RULE 1: Do NOT make a joke about MSFT. FORUM RULE 2: See rule 1. I could go on all night about pathetic the response was, to me making a joke, but I have more intesting thing to atttend to now. Happy to take it up again if necessary.
Nov 10 2017
prev sibling parent Satoshi <satoshi rikarin.org> writes:
On Friday, 10 November 2017 at 08:24:59 UTC, codephantom wrote:
 On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be 
 wise to learn for free from the money they spent.
Is that the same company that made Windows 10?
Not just the company, it's the same person who written MSDOS, Win 95, Windows Vista, 7, 8, 8.1, 10 and everything else in M$ because M$ is just one person company with some random guy who can write a thousands lines of code per hour.
Nov 10 2017
prev sibling next sibling parent Michael <michael toohuman.io> writes:
On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 On 11/6/17 12:20, Michael wrote:
[...]
You're right, I didn't, that was intentional, because sometimes people write things like that. And it took a while for anyone to say anything about it. That is my point. But that's the thing. The ?? is significantly more obvious in the condensed version. This is something that a UX designer would recognize instantly, but human factors are very definitely not our strong skill as engineers. FWIW, my human factors experience comes from the deep study of airline crashes that I do as a pilot.
[...]
Two things. ?: is ALSO a change a to language (lexer+parser). As to the whole "it's no more likely to typo the colon than the question" argument, sure, but that depends on the keyboard layout more than anything else, what works for you may not work elsewhere. And in either case, it's an easy compiler error. So you don't win anything with the ?:, but you win readability with the ??. MSFT spends a LOT of time studying these things. It would be wise to learn for free from the money they spent.
This is fair, though do we know Microsoft actually put research into their choice on this matter? Either way, it would be a nice addition, and my preference is for ?: but I'm sure the best case will win the others over.
Nov 10 2017
prev sibling next sibling parent reply meppl <mephisto nordhoff-online.de> writes:
On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 On 11/6/17 12:20, Michael wrote:
 I can't quite see why this proposal is such a big deal to 
 people - as
 has been restated, it's just a quick change in the parser for 
 a slight
 contraction in the code, and nothing language-breaking, it's 
 not a big
 change to the language at all.

 On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 I am all for the Elvis operator, however I have two 
 reservations about
 it. The first is that I don't see much use for it without a
 null-conditional. The second is that the current proposed 
 syntax ?: is
 MUCH to easily confused with ?.

 This is not easy to read: obj1?.obj2?.prop3?:constant.

 When designing syntax sugar, ergonomics are very important, 
 otherwise
 people won't use it. Microsoft spent a LOT of time and 
 treasure to
 learn these lessons for us. I see no reason to ignore them 
 just
 because "we don't like Microsoft"

 My proposal would be to copy what MSFT did, expect that I 
 would I
 would introduce both operators at the same time.

 Syntax as follows: obj1?.obj2?.prop3 ?? constant

 In practice I don't see much use of the idiom outside of 
 null's. The
 ONLY other thing that would work there is a boolean field and 
 you
 might as well just return the boolean itself because the 
 return values
 have to match types.
I feel this is kind of embellished somewhat. When you write
 This is not easy to read: obj1?.obj2?.prop3?:constant.
you're not separating it out as you do when you write your preferred version:
 Syntax as follows: obj1?.obj2?.prop3 ?? constant
How is
 obj1?.obj2?.prop3 ?: constant
not as easy to read as
 obj1?.obj2?.prop3 ?? constant
You're right, I didn't, that was intentional, because sometimes people write things like that. And it took a while for anyone to say anything about it. That is my point. But that's the thing. The ?? is significantly more obvious in the condensed version. This is something that a UX designer would recognize instantly, but human factors are very definitely not our strong skill as engineers. FWIW, my human factors experience comes from the deep study of airline crashes that I do as a pilot.
 to me they are the same in terms of readability, only with ?? 
 you have
 greater chances of mistyping and adding a second ? in there 
 somewhere,
 whereas the ?: is just a contraction of the current syntax, I 
 really
 don't think it's that difficult, so I'm not sure what people's 
 hang-ups
 are, but I don't think the argument that ?? is easier to read 
 than ?:
 holds any weight here, because one *is* a change to the 
 language, and
 the other is a change to the parser and a contraction of a 
 standard
 convention.
Two things. ?: is ALSO a change a to language (lexer+parser). As to the whole "it's no more likely to typo the colon than the question" argument, sure, but that depends on the keyboard layout more than anything else, what works for you may not work elsewhere. And in either case, it's an easy compiler error. So you don't win anything with the ?:, but you win readability with the ??. MSFT spends a LOT of time studying these things. It would be wise to learn for free from the money they spent.
I still dont get your point. Are you sure `??` isn't more readable for you, because you are just used to it? I think `?:` makes more sense to me and people who learn the D programming language. At least As log as `null` becomes `false` and non-null-pointer becomes `true`. If the operator shall check for `null` only, I would be fine with `??`. Because then it wouldn't be a true shortcut of https://dlang.org/spec/expression.html#ConditionalExpression anymore I wonder what Mr. Bright and Mr. Alexandrescu would say about the request to implement both, `??` and `?:`.
Nov 10 2017
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 10 November 2017 at 19:59:29 UTC, meppl wrote:
 On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 On 11/6/17 12:20, Michael wrote:
 I can't quite see why this proposal is such a big deal to 
 people - as
 has been restated, it's just a quick change in the parser for 
 a slight
 contraction in the code, and nothing language-breaking, it's 
 not a big
 change to the language at all.

 On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 I am all for the Elvis operator, however I have two 
 reservations about
 it. The first is that I don't see much use for it without a
 null-conditional. The second is that the current proposed 
 syntax ?: is
 MUCH to easily confused with ?.

 This is not easy to read: obj1?.obj2?.prop3?:constant.

 When designing syntax sugar, ergonomics are very important, 
 otherwise
 people won't use it. Microsoft spent a LOT of time and 
 treasure to
 learn these lessons for us. I see no reason to ignore them 
 just
 because "we don't like Microsoft"

 My proposal would be to copy what MSFT did, expect that I 
 would I
 would introduce both operators at the same time.

 Syntax as follows: obj1?.obj2?.prop3 ?? constant

 In practice I don't see much use of the idiom outside of 
 null's. The
 ONLY other thing that would work there is a boolean field 
 and you
 might as well just return the boolean itself because the 
 return values
 have to match types.
I feel this is kind of embellished somewhat. When you write
 This is not easy to read: obj1?.obj2?.prop3?:constant.
you're not separating it out as you do when you write your preferred version:
 Syntax as follows: obj1?.obj2?.prop3 ?? constant
How is
 obj1?.obj2?.prop3 ?: constant
not as easy to read as
 obj1?.obj2?.prop3 ?? constant
You're right, I didn't, that was intentional, because sometimes people write things like that. And it took a while for anyone to say anything about it. That is my point. But that's the thing. The ?? is significantly more obvious in the condensed version. This is something that a UX designer would recognize instantly, but human factors are very definitely not our strong skill as engineers. FWIW, my human factors experience comes from the deep study of airline crashes that I do as a pilot.
 to me they are the same in terms of readability, only with ?? 
 you have
 greater chances of mistyping and adding a second ? in there 
 somewhere,
 whereas the ?: is just a contraction of the current syntax, I 
 really
 don't think it's that difficult, so I'm not sure what 
 people's hang-ups
 are, but I don't think the argument that ?? is easier to read 
 than ?:
 holds any weight here, because one *is* a change to the 
 language, and
 the other is a change to the parser and a contraction of a 
 standard
 convention.
Two things. ?: is ALSO a change a to language (lexer+parser). As to the whole "it's no more likely to typo the colon than the question" argument, sure, but that depends on the keyboard layout more than anything else, what works for you may not work elsewhere. And in either case, it's an easy compiler error. So you don't win anything with the ?:, but you win readability with the ??. MSFT spends a LOT of time studying these things. It would be wise to learn for free from the money they spent.
I still dont get your point. Are you sure `??` isn't more readable for you, because you are just used to it? I think `?:` makes more sense to me and people who learn the D programming language. At least As log as `null` becomes `false` and non-null-pointer becomes `true`. If the operator shall check for `null` only, I would be fine with `??`. Because then it wouldn't be a true shortcut of https://dlang.org/spec/expression.html#ConditionalExpression anymore I wonder what Mr. Bright and Mr. Alexandrescu would say about the request to implement both, `??` and `?:`.
?: is a special case of the ternary operator of C. It is well established as extention in gcc and clang since forever. It is annoying that the C standard didn't incorporate it (afair because of Microsoft which didn't support it in Visual C) as it is quite practical. Someone in the thread claimed its poor value because it only saved 1 character typing but that argument is idiotic as it is not used to replace a?a:b with a?:b but rather with something more like that int code = holyshitbigassfunct(this, wathever, FOO, BAR); if(!code) code = -1; do_something(code); with do_something(holyshitbigassfunct(this, wathever, FOO, BAR) ?: -1); Ok, I made up that example, but it is the kind of things that I was able to replace in my C project when I started to allow the Elvis operator. I don't think that the benefit for D will be as spectacular as a lot of boilerplate can be avoided in other ways, but the message that I would like to bring over here, is that sometimes the benefit of a syntax sugar is not immediatly obvious when using the basic construct.
Nov 10 2017
prev sibling parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 19:59:29 UTC, meppl wrote:
 I wonder what Mr. Bright and Mr. Alexandrescu would say about 
 the request to implement both, `??` and `?:`.
Seriously? Implement both? I'm really not sure whether that's just meant to be humour or what. The first things that should be on everyones mind, is to avoid unnesecsary variations in a programming language. It's one of the things that many languages don't get. If D gets both, that'll be the end of my interest in D.
Nov 10 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be 
 wise to learn for free from the money they spent.
This is valid MSFT code, I believe: A?.B?.C?[0] ?? E A?.B?.C?[0] == E I have been coding on and off, since 1992, in various languages. So can you please tell what this code means? Can you please tell me what it was that MSFT learnt (and spent money to do so), so as to enable coders to write such code?
Nov 10 2017
prev sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
 MSFT spends a LOT of time studying these things. It would be 
 wise to learn for free from the money they spent.
I just saw this about the new 'damnit' operator, for C# 8. https://github.com/dotnet/csharplang/issues/556 I thought it was a joke at first, but they are serious. C# seem to becoming language of operators. ool? a, b; ... var x = !a! != b! ? a! : !b!; Yeah...lets follow there example...they seem to know better.
Nov 10 2017
parent Nick Treleaven <nick geany.org> writes:
On Saturday, 11 November 2017 at 05:20:39 UTC, codephantom wrote:
 I just saw this about the new 'damnit' operator, for C# 8.

 https://github.com/dotnet/csharplang/issues/556
The principle is a good one - by default you cannot dereference something that can be null, you get a compiler error instead. If you are confident it isn't null, you use a special operator to override the compiler check. This is better because: 1. The programmer has to acknowledge that the reference is nullable (except where the compiler may be able to prove it is not null). 2. People reading the code are informed that potentially the reference is null but the programmer thought it wouldn't be, in this particular case, documenting the programmer's understanding. 3. Reviewers are freed from checking r's possible assigned value in all code paths every time r is dereferenced. This solution is probably less disruptive to existing code than removing null altogether like Rust, which encourages the programmer to always handle the not-null and null case for every dereference. (Although half the battle is having non-null types).
Nov 13 2017
prev sibling next sibling parent reply Satoshi <satoshi rikarin.org> writes:
On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 On 10/28/17 04:38, Andrei Alexandrescu wrote:
 [...]
C# has extensive experience with this operator and I think it would be wise to study the history of what they did and why the did it. NOTE: I understand that other languages have it, and there are variations on the theme, but C# has many similarities to D and extensive "in practice" idioms. [...]
I strongly agree with you.
Nov 07 2017
parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 7 November 2017 at 09:42:50 UTC, Satoshi wrote:
 I strongly agree with you.
As I wrote earlier int this thread. Kotlin has the `?.` operator for the same reason. I honestly can't think of a more obvious operator for that purpose...
Nov 07 2017
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 On 10/28/17 04:38, Andrei Alexandrescu wrote:
 [...]
C# has extensive experience with this operator and I think it would be wise to study the history of what they did and why the did it. NOTE: I understand that other languages have it, and there are variations on the theme, but C# has many similarities to D and extensive "in practice" idioms. [...]
My problem with a null coalescing operator is that it bakes in one particular monad into the syntax, and it's not even a monad that's that useful for most idiomatic D code I've seen or written. I'd rather have do notation or something like that. Atila
Nov 07 2017
parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 7 November 2017 at 13:36:19 UTC, Atila Neves wrote:
 On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
 On 10/28/17 04:38, Andrei Alexandrescu wrote:
 [...]
C# has extensive experience with this operator and I think it would be wise to study the history of what they did and why the did it. NOTE: I understand that other languages have it, and there are variations on the theme, but C# has many similarities to D and extensive "in practice" idioms. [...]
My problem with a null coalescing operator is that it bakes in one particular monad into the syntax, and it's not even a monad that's that useful for most idiomatic D code I've seen or written. I'd rather have do notation or something like that. Atila
There's a big problem in the discussion here. Everyone opposed to the operator keeps repeating that it's not that useful for most idiomatic D code. However I'd argue as far to say D has two idioms. The "low-level" idiom which is what most people would say is a typical D idiom. Passing structs around etc. This idiom is typically seen in the core of D such as Phobos, D Runtime etc. However there's another idiom to D, which is what I'll call the "high-level" idiom which is mostly people writing applications with libraries such as vibe.d, which heavily relies on classes and reference types passed around, rather then structs. Another example of what I'd call "high-level" idiom is libraries like "dlangui" which also heavily relies on classes, a common idiom for UI applications. Saying that using classes and types that can be null referenced ins't idiomatic D is wrong IMO. I agree the elvis operator wouldn't have much purpose without something like the null-conditional operator. If D truly wants to expand further than a hobby language, then we'd have to focus on enterprise development, which D will never reach with a mentality like this. C# is a good reference for an ideal language that's fit for enterprise development and D could learn a lot from the language. I think we have a problem in this community to always bash down things with "It can be solved as a library.", "I don't see the value of this being added.", "I'm not going to use this feature, so nobody else will." Instead we should be like: "This will make the language more clean, since we don't need to have unnecessary imports and ten different implementations for the same thing.", "Personally this has no value to my code, because of 'X', but I could see how it could help people writing code like 'Y'", "I'm not going to use this feature, but I can see how it might be useful to others." I understand the mentality of people who believe it has a cost to add something, because it's another idiom to learn, but ask yourself this? What's easier to learn? A couple operators (elvis, null-conditional ...) or 10 different module names for all your 3rd party libraries and their implementations doing the same thing as the operators that could be implemented. Even when something exist in Phobos, people forget about it and end up writing their own implementations that do the exact same, because we're humans and humans forget. Sometimes it can be hard to remember exact modules where some functionality is implemented and that's the down-side of library solutions. You have to remember which module something belongs to. A language solution however doesn't have that problem, because you don't have to memorize anything other than the syntax of the operators. You don't have to remember any names of modules or any names of functions, their parameters or return types. You just have to remember the operator and in which order it takes its arguments. Language implementations are usually much simpler and are better suited for optimizations too. Don't get me wrong though, I don't believe this operator is life or death, neither do I believe that it's one of the most important things to be implemented. Yes there are other things more important to implement, but it doesn't mean this operator shouldn't be implemented; maybe not now, but in the future. I believe we're too quick in this community to shut down good ideas, because we believe other problems have better priority. Instead of shutting good ideas down, we need to queue them, so they don't get shut down, but aren't prioritized. Yes there are more important things than implementing the so called elvis operator and we should definitely focus on that instead, but we shouldn't entirely shut down the idea of implementing such a feature, just because D has bigger and more prioritized issues.
Nov 07 2017
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 7 November 2017 at 14:08:07 UTC, bauss wrote:
 [snip]

 However there's another idiom to D, which is what I'll call the 
 "high-level" idiom which is mostly people writing applications 
 with libraries such as vibe.d, which heavily relies on classes 
 and reference types passed around, rather then structs. Another 
 example of what I'd call "high-level" idiom is libraries like 
 "dlangui" which also heavily relies on classes, a common idiom 
 for UI applications.
A DIP could probably include examples of how vibe.d and dlangui handle nulls and how whatever solution is proposed would be simpler.
Nov 07 2017
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 7 November 2017 at 14:08:07 UTC, bauss wrote:
 I think we have a problem in this community to always bash down 
 things with "It can be solved as a library.", "I don't see the 
 value of this being added.", "I'm not going to use this 
 feature, so nobody else will."
It is considered good practice in language design to first insist on a library solution and only implement it in the language iff 1. it turned out to be a useful feature 2. a library implementation was inadequate Ola.
Nov 07 2017
parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 7 November 2017 at 16:32:50 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 7 November 2017 at 14:08:07 UTC, bauss wrote:
 I think we have a problem in this community to always bash 
 down things with "It can be solved as a library.", "I don't 
 see the value of this being added.", "I'm not going to use 
 this feature, so nobody else will."
It is considered good practice in language design to first insist on a library solution and only implement it in the language iff 1. it turned out to be a useful feature 2. a library implementation was inadequate Ola.
Which this operator has already proven to be in other successful languages.
Nov 07 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 7 November 2017 at 17:27:30 UTC, bauss wrote:
 Which this operator has already proven to be in other 
 successful languages.
Not exactly this variation, but I get your point. On the other hand, so has hundreds of other operators from other languages... So which one should one not implement? Anyway, I've already shared my viewpoints on the flaws of "?:" as proposed.
Nov 07 2017
parent bauss <jj_1337 live.dk> writes:
On Tuesday, 7 November 2017 at 17:37:42 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 7 November 2017 at 17:27:30 UTC, bauss wrote:
 Which this operator has already proven to be in other 
 successful languages.
Not exactly this variation, but I get your point. On the other hand, so has hundreds of other operators from other languages... So which one should one not implement? Anyway, I've already shared my viewpoints on the flaws of "?:" as proposed.
Yes. My point wasn't entirely for the addition of this operator, but in general for every good idea around here. Honestly I don't care too much if it gets implemented or not. It'll be a great addition, but in my own opinion it's not life or death.
Nov 07 2017