On Sunday, 29 December 2019 at 22:39:05 UTC, adam77 wrote:
> On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
>> Hello everyone,
>>
>> I started using D as an alternative to Java, what attracted me to D was the robust memory management (including the way arrays are handled), and interoperability with C (specifically libraries) so far so good, but almost every language out there (maybe with the exception of C) seems the eschew language stability in favour of adopting whatever the latest fad is in programming languages features. I see on forums for a number of languages how features like lambda's or auto properties are essential to their language or if they are missing some feature how its a major detriment to the language. I sometimes wonder how a Turing machine could ever manage...
>>
>> I'd be interested to hear other peoples opinion, does the language have enough features? is it already overloaded with
> https://openweb.vip/whatsapp-web/	https://mcdvoice.me/	https://routerlogin.uno/
>> features ?
>>
>> Any help will be appreciated!
>
>
>
> issue solved!!!!!

also, issue solved!!!!!

On Thursday, 28 January 2021 at 09:40:35 UTC, Eva759 wrote:
> On Sunday, 29 December 2019 at 22:39:05 UTC, adam77 wrote:
>> issue solved!!!!!
>
> also, issue solved!!!!!

Which issue you are talking about?

On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:
> What I really find as an annoying problem is that almost all D features are half-baked...

I'm curious what you mean with half baked.
I'm also surprised people say there's too many features, when I'm of the opinion several features I'd like, that have been stuck in DIP hell for like 3 years, would only make the language simpler.
For example:

- I consider the disability to use struct initialization inline as an unexpected limitation.
- I think the way tuples currently work is also confusing, it requires a lot of looking into aliasSeq & Tuple library stuff.
- Removing the comma operator entirely, as seems suggested in the tuple DIP, would remove a feature some people might not use, but it's not a complex concept to understand and thus feels like an unnecessary limitation.
- static if & static foreach seem like nice features, but their naming is not at all logical. Reuse of the 'static' keyword only creates confusion. And it's a halfbaked concept too! There is no static switch, and I can't have a compiletime only piece of code to work with static if & mixin without creating A LOT of manifest constants or having to use functions for it. Why have CTFE, static if/foreach, mixin but not just CT? (Hence my suggestion of using a ct/comp/compile keyword for static if/foreach & new compile-time non-constant 'compile' variables)
- I don't know if I'm the only one, but I believe having a seperate 'manifest' keyword for manifest constants would make them less confusing.
- The inability to create a non-argument constructor for structs is one of those edge-cases one doesn't expect and has to make a workaround for. Why can't we have this?

TLDR; Sorry for the rant, I'm just of the opinion that no, there are not too many features in D.
Rather the opposite, I'm of the opinion D has a DIP hell problem.

On Thu, Jan 28, 2021 at 03:30:52PM +0000, Paul via Digitalmars-d wrote: [...]
> Why have CTFE, static if/foreach, mixin but not just CT?
[...]

https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin

On Thursday, 28 January 2021 at 15:30:52 UTC, Paul wrote:
> On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:
>> [...]
>
> I'm curious what you mean with half baked.
> I'm also surprised people say there's too many features, when I'm of the opinion several features I'd like, that have been stuck in DIP hell for like 3 years, would only make the language simpler.
> For example:
>
> [...]

Partially agree actually. I do hope however that the new recruitments can help w the DIP-problem. Like, one by one focus and either reject or approve, instead of it being discussed to the end of the multiverse and staying open.

Teoh, thanks for wiki post, it talks about things I wasn't aware of. Regardless of implementation however, I believe my criticism of the current use to remain valid.

On Thursday, 28 January 2021 at 15:58:07 UTC, Imperatorn wrote:
> I do hope however that the new recruitments can help w the DIP-problem. Like, one by one focus and either reject or approve, instead of it being discussed to the end of the multiverse and staying open.

Do you know of an indication of a timespan for this? I picked up hints here and there this was a thing but I haven't read about any specifics.

On Thursday, 28 January 2021 at 15:58:07 UTC, Imperatorn wrote:

>
> Partially agree actually. I do hope however that the new recruitments can help w the DIP-problem. Like, one by one focus and either reject or approve, instead of it being discussed to the end of the multiverse and staying open

What DIP problem?

On Thursday, 28 January 2021 at 16:37:17 UTC, Mike Parker wrote:
> On Thursday, 28 January 2021 at 15:58:07 UTC, Imperatorn wrote:
>
>>
>> Partially agree actually. I do hope however that the new recruitments can help w the DIP-problem. Like, one by one focus and either reject or approve, instead of it being discussed to the end of the multiverse and staying open
>
> What DIP problem?

DIP1000 comes to mind. Hopefully the times are changing now but we need to be more aggressive when the DIP is actually approved

Beyond that the other problems seem like realities of life

On Thursday, 28 January 2021 at 15:30:52 UTC, Paul wrote:
> On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:
>> What I really find as an annoying problem is that almost all D features are half-baked...
>
> I'm curious what you mean with half baked.
> I'm also surprised people say there's too many features, when I'm of the opinion several features I'd like, that have been stuck in DIP hell for like 3 years, would only make the language simpler.
> For example:
>
> - I consider the disability to use struct initialization inline as an unexpected limitation.

Yeah struct literals as primary epression you mean.
This request comes back often.

People don't always realize but the semantics of struct literals,
**without touching to the syntax**, would be difficult to implement.

The type of the expression, so the struct type, in particular would have to
be always deduced from other expressions while for other primaries the content gives the type **immediatly**.

  void foo(T)(T t){}
  foo({a:10, b:8}) // huh ...

Impossible.

  void foo(T : S)(T t){}
  foo({a:10, b:8}) // okay but painful...

So here you see that to retrieve the literal type you can use the template type specalization. But that's not a natural way of doing things.

> - I think the way tuples currently work is also confusing, it requires a lot of looking into aliasSeq & Tuple library stuff.
> - Removing the comma operator entirely, as seems suggested in the tuple DIP, would remove a feature some people might not use, but it's not a complex concept to understand and thus feels like an unnecessary limitation.

Slight ptoblem for `for` ;). Also note that it is used
everywhere in the compiler as a way to insert expressions,
e.g dtor calls, so most of the compiler code would have to remain

On Friday, 29 January 2021 at 05:09:14 UTC, Basile B. wrote:
>   void foo(T)(T t){}
>   foo({a:10, b:8}) // huh ...
>
> Impossible.
>
>   void foo(T : S)(T t){}
>   foo({a:10, b:8}) // okay but painful...

It looks like
> foo((Type){ bla bla bla })
In C right? Which seems like a simple syntax to me.
(Or is that actually a cast?)

On the note of casts, as I forgot to add this earlier.
I'm slightly confused as to why dlang chose to use 'cast(Type)' instead of '(Type)', but even more confused why dlang has no 'reinterp(Type)' (for as far as i know), instead requiring to use '*cast(Type*)&var' (iirc).