Thread overview
Some suggestions for the d language
September 18
I had some suggestions for the d language that I think would improve it a bunch.

1. var keyword for autodetect of auto and mixin.
this is just a optional way of typing auto and mixin. automatically detects which one.

2. optional use of <> instead of !() and (). for templates.
coming from the C# language it's my opinion it's easier to type and is more readable.

3. coroutines (aka async functions) and yield overloads
being able to execute functions and yield from them...

bool coroutine(bool done)
{
  yield(false      );
  yield(false,    3); //yields for 3 seconds (double)
  yield(false, done); //yields until done is true (bool)
  return true;
}


September 19
On Wednesday, 18 September 2019 at 21:03:36 UTC, Shadowblitz16 wrote:
> I had some suggestions for the d language that I think would improve it a bunch.
>
> 1. var keyword for autodetect of auto and mixin.
> this is just a optional way of typing auto and mixin. automatically detects which one.
>
> 2. optional use of <> instead of !() and (). for templates.
> coming from the C# language it's my opinion it's easier to type and is more readable.
>
> 3. coroutines (aka async functions) and yield overloads
> being able to execute functions and yield from them...
>
> bool coroutine(bool done)
> {
>   yield(false      );
>   yield(false,    3); //yields for 3 seconds (double)
>   yield(false, done); //yields until done is true (bool)
>   return true;
> }
1. Why?

2. No, the reason why D uses ! Instead of <> is to make the compiler saner to implement.

3. Fibers are available in the standard library, which implement coroutines

September 19
On Thursday, 19 September 2019 at 05:05:51 UTC, Max Haughton wrote:
> On Wednesday, 18 September 2019 at 21:03:36 UTC, Shadowblitz16 wrote:
>> I had some suggestions for the d language that I think would improve it a bunch.
>>
>> 1. var keyword for autodetect of auto and mixin.
>> this is just a optional way of typing auto and mixin. automatically detects which one.
>>
>> 2. optional use of <> instead of !() and (). for templates.
>> coming from the C# language it's my opinion it's easier to type and is more readable.
>>
>> 3. coroutines (aka async functions) and yield overloads
>> being able to execute functions and yield from them...
>>
>> bool coroutine(bool done)
>> {
>>   yield(false      );
>>   yield(false,    3); //yields for 3 seconds (double)
>>   yield(false, done); //yields until done is true (bool)
>>   return true;
>> }
> 1. Why?
>
> 2. No, the reason why D uses ! Instead of <> is to make the compiler saner to implement.
>
> 3. Fibers are available in the standard library, which implement coroutines

1. var is easier to type and would be basically a universal type.

2. right now is confusing to use.
it might be harder to implement, but it makes code cleaner and more readable.

3. I would rather not have to call a function for coroutines to create them.
its alot easier to just yield out of a function. of course if this slows the language down it would be bad.

I think the language should auto detect if a yield is used and execute and store a coroutine until it is finished.
September 20
On Thursday, 19 September 2019 at 18:39:42 UTC, Shadowblitz16 wrote:
> On Thursday, 19 September 2019 at 05:05:51 UTC, Max Haughton wrote:
>> On Wednesday, 18 September 2019 at 21:03:36 UTC, Shadowblitz16 wrote:
>>> I had some suggestions for the d language that I think would improve it a bunch.
>>>
>>> 1. var keyword for autodetect of auto and mixin.
>>> this is just a optional way of typing auto and mixin. automatically detects which one.
>>>
>>> 2. optional use of <> instead of !() and (). for templates.
>>> coming from the C# language it's my opinion it's easier to type and is more readable.
>>>
>>> 3. coroutines (aka async functions) and yield overloads
>>> being able to execute functions and yield from them...
>>>
>>> bool coroutine(bool done)
>>> {
>>>   yield(false      );
>>>   yield(false,    3); //yields for 3 seconds (double)
>>>   yield(false, done); //yields until done is true (bool)
>>>   return true;
>>> }
>> 1. Why?
>>
>> 2. No, the reason why D uses ! Instead of <> is to make the compiler saner to implement.
>>
>> 3. Fibers are available in the standard library, which implement coroutines
>
> 1. var is easier to type and would be basically a universal type.
>
> 2. right now is confusing to use.
> it might be harder to implement, but it makes code cleaner and more readable.
>
> 3. I would rather not have to call a function for coroutines to create them.
> its alot easier to just yield out of a function. of course if this slows the language down it would be bad.
>
> I think the language should auto detect if a yield is used and execute and store a coroutine until it is finished.

1. I guess, but again is it really an issue? If I'm reading you correctly, does inferring mixin from var even make sense semantically?

2. How is: "range.map!min" confusing compared to "range.map<min>"? Also, implementing this would require modifying the compiler *a lot*. D is specifically designed not to use this feature because ! is not a binary operator whereas < > are (To resolve this the parser has to have access to the symbol table)

3. You have to call something even if it's hidden. I would actually prefer coroutines or similar to be in the core language (It's very difficult if not impossible to check whether a function even attempts to call yield for example) but what is there works atm
September 20
On Friday, 20 September 2019 at 01:35:52 UTC, Max Haughton wrote:
> On Thursday, 19 September 2019 at 18:39:42 UTC, Shadowblitz16 wrote:
>> On Thursday, 19 September 2019 at 05:05:51 UTC, Max Haughton wrote:
>>> On Wednesday, 18 September 2019 at 21:03:36 UTC, Shadowblitz16 wrote:
>>>> [...]
>>> 1. Why?
>>>
>>> 2. No, the reason why D uses ! Instead of <> is to make the compiler saner to implement.
>>>
>>> 3. Fibers are available in the standard library, which implement coroutines
>>
>> 1. var is easier to type and would be basically a universal type.
>>
>> 2. right now is confusing to use.
>> it might be harder to implement, but it makes code cleaner and more readable.
>>
>> 3. I would rather not have to call a function for coroutines to create them.
>> its alot easier to just yield out of a function. of course if this slows the language down it would be bad.
>>
>> I think the language should auto detect if a yield is used and execute and store a coroutine until it is finished.
>
> 1. I guess, but again is it really an issue? If I'm reading you correctly, does inferring mixin from var even make sense semantically?
>
> 2. How is: "range.map!min" confusing compared to "range.map<min>"? Also, implementing this would require modifying the compiler *a lot*. D is specifically designed not to use this feature because ! is not a binary operator whereas < > are (To resolve this the parser has to have access to the symbol table)
>
> 3. You have to call something even if it's hidden. I would actually prefer coroutines or similar to be in the core language (It's very difficult if not impossible to check whether a function even attempts to call yield for example) but what is there works atm

1. no not really it just would be a nice thing to have.

2. I agree this would require alot of work, but I think if someone was willing to do it it would make it the language alot nicer even if it was optional syntax.

3. this could be fixed by adding is_coroutine(function) or something; but why would you need to check it anyway? it just would be a nice way of doing asynchronous programming in the d language.
September 20
On Friday, 20 September 2019 at 03:00:03 UTC, Shadowblitz16 wrote:
> On Friday, 20 September 2019 at 01:35:52 UTC, Max Haughton wrote:
>> [...]
>
> 1. no not really it just would be a nice thing to have.
>
> 2. I agree this would require alot of work, but I think if someone was willing to do it it would make it the language alot nicer even if it was optional syntax.
>
> 3. this could be fixed by adding is_coroutine(function) or something; but why would you need to check it anyway? it just would be a nice way of doing asynchronous programming in the d language.

It would literally mean ripping the entire parser and possibly lexer to bits while also probably force the semantic analysis to be done synchronously.
September 20
On Wednesday, 18 September 2019 at 21:03:36 UTC, Shadowblitz16 wrote:
> I had some suggestions for the d language that I think would improve it a bunch.

Don't worry. You have a cognitive bias. You have just to become confortable with D syntax.