Re: Anyone interested in mentoring?

2023-07-12 Thread Mike Parker via Digitalmars-d-announce
On Wednesday, 12 July 2023 at 16:56:45 UTC, Emmanuel Danso Nyarko 
wrote:


Thank you very much Mike. Will early submissions help my 
application?


No. That's not a factor in the selection process.


Re: Anyone interested in mentoring?

2023-07-12 Thread Emmanuel Danso Nyarko via Digitalmars-d-announce

On Tuesday, 11 July 2023 at 16:37:39 UTC, Mike Parker wrote:

On Tuesday, 11 July 2023 at 02:18:34 UTC, Emmanuel wrote:
I would like to work on the interoperability between C++ 
associative containers and the D language.


Is this for a SAOC project application? If so, please feel free 
to submit the application without a mentor attached. If you 
later find one before the deadline, you can let me know and 
I'll amend the application.


You might also ask in the community's Discord:

https://discord.com/invite/bMZk9Q4


Thank you very much Mike. Will early submissions help my 
application?


Re: Anyone interested in mentoring?

2023-07-12 Thread Emmanuel Danso Nyarko via Digitalmars-d-announce

On Tuesday, 11 July 2023 at 15:52:54 UTC, Ferhat Kurtulmuş wrote:

On Tuesday, 11 July 2023 at 02:18:34 UTC, Emmanuel wrote:
I would like to work on the interoperability between C++ 
associative containers and the D language.


I am so sad that this forum has a lot of orphan entries 
recently. I don't know which kind of mentorship you need. I 
cannot provide any level of it, but I would start forking DMD 
and work on stdcpp folder. Take a look at how std::vector is 
wrapped in druntime for instance.




https://github.com/dlang/dmd/tree/master/druntime/src/core/stdcpp

The mentorship I need is for the SAOC application. I just checked 
stdvector out and it is a great piece. I'll be researching more 
into it. Thanks





Re: Evolving the D Language

2023-07-12 Thread Nick Treleaven via Digitalmars-d-announce

On Sunday, 9 July 2023 at 18:51:01 UTC, IchorDev wrote:

On Friday, 7 July 2023 at 13:19:51 UTC, Nick Treleaven wrote:
Changing the syntax just for an obsolete feature would send 
the wrong message.

[...]
cent and ucent are already an error as of 2.100. Were they 
even implemented?


Clearly you're not looking at this the same way as me, [or 
Walter](https://github.com/dlang/dmd/pull/15393).
Fixing old code isn't the only upside to resurrecting old 
features.


I thought Walter was asking for features that should be changed 
from deprecated to obsolete, it seems I was wrong.


First thing, I think all languages should support binary, 
octal, decimal and hexadecimal literals as a baseline. Octal is 
probably the least important of them, but can still be plenty 
useful in its own right.


Generally programmers can count in binary and decimal, hex 
somewhat. Not octal.


You technically don't need *any* numerical literals at all in 
D, you could make all of them with string-to-number templates. 
You could take such an approach to just about everything in D, 
actually! On the other hand, people working on low-level Linux 
code might be pretty appalled to find out that they can't 
simply use octal literals to represent file permissions in D.


Maybe because they're used to working in languages that don't 
have D's CTFE abilities. Octals are still rare. There are other 
literals, not all literals can be supported in the language. So 
the better solution for less common literals is to embrace the 
library pattern and dogfood it. C++ has user-defined literal 
support. D doesn't need that.


...
There are a few D features that were poorly implemented (or not 
implemented at all), and then simply removed instead of being 
fully reconsidered. You might say that for many, they were 
indeed reconsidered, and then added to Phobos instead. Now some 
of these features pre-date BetterC, of course, but I am a 
regular BetterC user. A feature being moved to Phobos 
translates to "you don't get to use this in most of your code 
anymore" for me.


`octal` could have been added to druntime, or you can copy the 
code. For betterC there's probably quite a lot of stuff in Phobos 
that works with betterC, so that is a general problem.


I'm not a user of complex or imaginary types, but I don't see 
why they needed to be removed from D, were they a huge burden 
to maintain compared to being in Phobos?


It depends whether you value language simplification and 
dogfooding.