On Saturday, 16 June 2018 at 05:48:26 UTC, Nick Sabalausky (Abscissa) wrote:
> But short of that...no sugar is likely to happen anytime soon that isn't library-based, I'm genuinely sorry to report :(

Most of these just seem like an easy win on the attractiveness of D.
Big benefits of language based sugar is good tooling and debugging support.
Not only would that make the language more attractive to outsiders who did have those things in other languages and refuse to use D whitout, but if properly implemented limit the strain on the brain of the programmer which opens up D to a new set of programmers.

The reason I don't like library support in particular because you can't alway rely on a library, they take some time setting up, and maybe the open source project you're contributing to doesn't want libraries whatever how small.
When people do use a library there is always licencing to think about and maybe, just maybe they chose a library you're already familiar with and you won't have to re-learn known concepts from a different library. (This last one is a real dealbreaker for me)

Maybe in time, if a particular library is proven to be superior over existing syntax it'll get language support.
But with the mantra "fast code, fast" I'm frankly kind of disappointed that such desicions weren't done before.

I realize I missed out on some very usefull libraries and I'll look in to them and most likely start using them, but untill most of these things are implemented I still have this sour feeling in my mouth.

Maybe some syntactic sugar will solve that. :P

On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
> For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D.
>
> * The null conditional operator `?.`

Yeah, me too. I have to say that at least D is expressive enough to allow the safeAccess template, as mentioned before, although there are several drawbacks: it's in many cases sub-optimal, it's not autocompletion-friendly at all, it's less distinguishable from an operator.

But well, really it's nice that it's possible as a template. No need to harass the language leaders for that.

On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
> For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D.
>
> * The null conditional operator `?.`

This has been discussed many times and would definitely require a DIP and a good usecase. I'm all in support for this one.

> * Something like a `yield return` statement for coroutines.

D has ranges and doesn't need statemachines like C#.

> T* he `async` & `await` keyword from C# make proactor pattern

D uses fibers and calling the yield() function has pretty much same behavior.

The major difference is your async code looks synchronous and thus more natural.

D is a clear winner on this one IMO.


> async code extremely easy to reason about.

See above.

> * a good syntax for properties so there's less code bloat.

I agree with this, but will probably never happen.

> * replacing `Allocator.make()` with `new!Allocator`. After all `new` can be concidered as just a wrapper around the standard

Not sure about this. The less ties the language has to the library, the better.

> GC allocator. Why can't we just have a special template of it?
>

Above.

> I have realized that I have become quite dependant on syntactic sugar to the point that it severely impacts my productivity when I work whitout. And these ones are my biggest obstacles when I try to work with D from a C# experience. I think that C# really nailed down some of these particular examples except the last one of course.
> And I also think D could do a better job of embracing productivity through supporting syntax of common tasks and borrow from other languages in that regard.
>
> But the most important question is how other people feel about that.
> If people hate syntactic sugar D will never become that gem for me that I would like it to be. But if key people want it, it one day might.

All in all.

D requires a DIP for each and very good usecase. Not just "I think they're useful and I'd like them"

On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
> For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D.
>

First of all, it’s not missing but deliberately not added for many reason, which I’m sure other folks from core team will provide and correct me where applicable.

> * The null conditional operator `?.`

Might be interesting but we need to try more principled approach alng the line of Option!T type with nice accessors and maybe even make non-null a default. The latter will take not a single year though. But peppering language with more built-in magic is not our direction, I’m pretty certain of that.

> * Something like a `yield return` statement for coroutines.

That was on the radar actually, and would encode stackless automation wrapped as InputRange. Problem is how to get it to be say forward range (i.e. state saving would really be nice to include). For stackfull we have std.concurrency.Generator in library code just fine (IIRC).

> T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about.

God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes.

‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well.

> * a good syntax for properties so there's less code bloat.
> * replacing `Allocator.make()` with `new!Allocator`. After all `new` can be concidered as just a wrapper around the standard GC allocator. Why can't we just have a special template of it?

Is  a good idea, but syntactic sugar is smallest part of this problem if at all.

>
> I have realized that I have become quite dependant on syntactic sugar to the point that it severely impacts my productivity when I work whitout. And these ones are my biggest obstacles when I try to work with D from a C# experience.

Yeah it won’t be smooth then I could see.

> I think that C# really nailed down some of these particular examples except the last one of course.
> And I also think D could do a better job of embracing productivity through supporting syntax of common tasks and borrow from other languages in that regard.
>
> But the most important question is how other people feel about that.
> If people hate syntactic sugar D will never become that gem for me that I would like it to be. But if key people want it, it one day might.

On 6/15/18 8:53 PM, Seb wrote:
> On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote:
>> On Sat, Jun 16, 2018 at 12:20:35AM +0000, Seb via Digitalmars-d wrote:
>>> On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
>>> > For someone coming from a C# background there is some > seemingly 
>>> simple syntactic sugar missing from D.
>>> > > * The null conditional operator `?.`
>>>
>>> e.g. SafeAccess
>>>
>>> https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551 
>>>
>>
>> Didn't Andrei propose an Elvis operator some time ago? Whatever became of that DIP?
>>
>>
>> T
> 
> https://forum.dlang.org/post/ot1q8b$23pt$1@digitalmars.com
> https://github.com/dlang/dmd/pull/7242
> 
> I think Razvan focused on other projects no one else bothered enough to write a DIP about this.

I don't know if this is the same thing. I'm not a (recent) C# developer, but in Swift, ?. means something completely different from ?: in Andrei's proposal.

-Steve

On Saturday, 16 June 2018 at 18:49:43 UTC, Steven Schveighoffer wrote:
> On 6/15/18 8:53 PM, Seb wrote:
>> On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote:
>>> On Sat, Jun 16, 2018 at 12:20:35AM +0000, Seb via Digitalmars-d wrote:
>>>> On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
>>>> > For someone coming from a C# background there is some > seemingly
>>>> simple syntactic sugar missing from D.
>>>> > > * The null conditional operator `?.`
>>>>
>>>> e.g. SafeAccess
>>>>
>>>> https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551
>>>>
>>>
>>> Didn't Andrei propose an Elvis operator some time ago? Whatever became of that DIP?
>>>
>>>
>>> T
>> 
>> https://forum.dlang.org/post/ot1q8b$23pt$1@digitalmars.com
>> https://github.com/dlang/dmd/pull/7242
>> 
>> I think Razvan focused on other projects no one else bothered enough to write a DIP about this.
>
> I don't know if this is the same thing. I'm not a (recent) C# developer, but in Swift, ?. means something completely different from ?: in Andrei's proposal.
>
> -Steve

Yes, Andrei's proposal was for the equivalent of ?? in C#.

int* p = null;
int n = p ?: 42;
assert(n == 42);

On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
> For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D.
>
> * The null conditional operator `?.`

Null-safe dereference operator, I think it's called?

Hrm, my first impulse was in favor. I find this useful in Kotlin and I miss it when using Java. In D, I don't encounter null very often at all.

> * Something like a `yield return` statement for coroutines.

For iterables, more like? If you want a userspace thread, Fiber gives you this. But it can be annoying right now to write a range.

> T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about.

http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Maybe not the best. It's useful when you want to execute a small fixed number of heterogeneous things in parallel, but the cost is that everyone has to choose whether to make their thing run asynchronously or synchronously, and there's going to be pressure to make everything that could take more than a few milliseconds to go asynchronous. This would force almost every program to be multithreaded.

> * a good syntax for properties so there's less code bloat.

C# has syntax like:
  public int Something { get; set; }

It does this to make it easier to switch out a field for a computed property, to add validation to a field, and to let you put properties into interfaces.

D code typically doesn't use interfaces much, and you don't have to do anything special to convert a field into a getter/setter pair.

The only case where D loses out is compared to { get; private set; }.

> * replacing `Allocator.make()` with `new!Allocator`. After all `new` can be concidered as just a wrapper around the standard GC allocator. Why can't we just have a special template of it?

allocator.make!Foo(args)
new!allocator Foo(args)

One character difference. Doesn't seem like a big deal.

On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
> The only case where D loses out is compared to { get; private set; }.
>

That's a pretty big thing to give up. That allows for pretty valuable control over visibility of encapsulated properties.

On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet wrote:
> On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
>> The only case where D loses out is compared to { get; private set; }.
>>
>
> That's a pretty big thing to give up. That allows for pretty valuable control over visibility of encapsulated properties.

He means that in D this is split like that, which isn't as clean as C# does

class MyClass
{
  private int _myProp; // backing field
  private @property void myProp(int a) { _myProp = a; } // private setter
  public @property int myProp() { return _myProp; } // getter
}

On Monday, 18 June 2018 at 01:06:48 UTC, evilrat wrote:
> On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet wrote:
>> On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
>>> The only case where D loses out is compared to { get; private set; }.
>>>
>>
>> That's a pretty big thing to give up. That allows for pretty valuable control over visibility of encapsulated properties.
>
> He means that in D this is split like that, which isn't as clean as C# does
>
> class MyClass
> {
>   private int _myProp; // backing field
>   private @property void myProp(int a) { _myProp = a; } // private setter
>   public @property int myProp() { return _myProp; } // getter
> }

Well the cool part about D is that we can generate such sugar without necessarily needing to have it in the language (though a better property syntax would be great).
Anyhow here's an example from the accessors package (https://github.com/funkwerk/accessors):

import accessors;

class WithAccessors
{
    @Read @Write
    private int num_;
    // list all your fields here

    mixin(GenerateFieldAccessors);
}