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

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.



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.



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:


 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.



 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




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 




most devs only use it like so: a != null ? a : b.

The funny thing is that it was almost never used.


?. 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



 operator: ?. which allows you to write: obj1?.obj2?.prop3 ?? 
 constant.

 NOW people start using Null Coalescing all over the place.



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

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

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.
Nov 10 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Friday, 10 November 2017 at 11:19:39 UTC, Satoshi wrote:





it up.
Have designed/developed apps for large corporates.



I don't think looking to MSFT for programming language advice is 

let them argue their case, not try to silence me.







Still, to this day, trying to get itself out of the Windows only 
world.

What a joke.


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:





 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...








 I don't think looking to MSFT for programming language advice 

 ok, let them argue their case, not try to silence me.


Nobody is trying to silent you, you just started trolling there.







 Still, to this day, trying to get itself out of the Windows 
 only world.

 What a joke.


 still catching up..


How many corporations is using D right now? 10?
Windows is still dominant OS and there are a lot of job 


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 


 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.



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
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 


 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 

I'm not bagging D I'm just providing my personal opinions, 
experience and expectations.




 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 






I'm sharing my experience and expectations.



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:




 D. So I'm sharing my experience and expectations.



 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.




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:






- 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.

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 


MSFT have spent the last 7 years mostly adding useless stuff to 

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:







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


 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!)



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.




anything... I mean really...they just push button and have no 
idea whats going on.




 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.




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.




 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 



 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.









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 

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 

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 

 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. 

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. 

 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 

 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:







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.



 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 



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 

 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 

 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 

 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.




 https://github.com/dotnet/csharplang/issues/556

 I thought it was a joke at first, but they are serious.



 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.




 https://github.com/dotnet/csharplang/issues/556

 I thought it was a joke at first, but they are serious.



 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 


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 

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.



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 know all to well.



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 

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 


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

 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


 Wow!


I "had a go at you," because it seemed like you were bashing on Adam for

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,

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

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 

 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.

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.

 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.




https://github.com/dotnet/csharplang/issues/556

I thought it was a joke at first, but they are serious.



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:



 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:

 [...]




 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 

 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:

 [...]




 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 

 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:

 [...]




 would be wise to study the history of what they did and why 
 the did it. NOTE: I understand that other languages have it, 

 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.


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