On 15.02.2018 21:38, Walter Bright wrote:
> On 2/10/2018 4:35 AM, Timon Gehr wrote:
>> In summary, the issue is that there is only one 'inout' and therefore it is not properly lexically scoped. It is a bit like having a language where all variables are implicit function parameters and they all have the same, global, name. This sort of works fine until you want a function with two parameters or until you want to nest functions in a non-trivial way.
> 
> This needs to be filed on bugzilla. Shall I do it, or do you want to?

I had already filed the concrete counterexamples:

https://issues.dlang.org/show_bug.cgi?id=17743
https://issues.dlang.org/show_bug.cgi?id=17744

Should there be more?

On Friday, 9 February 2018 at 19:01:30 UTC, H. S. Teoh wrote:

> If somebody *paid* me to work on dub, then perhaps I will.  But right now, my level of motivation and interest in doing so is pretty low, and is on the losing side of the competition against the myriad other projects that I could be working on.
>
>
> T

I've paid John Colvin in the past out of my own pocket to work on dub.  Some of our pull requests were accepted, some are stuck in the queue. We have too much to do currently for core people to work on it, but if there are things that would make a difference for us and others we could explore sponsoring further development.

If we could make a list of what needs doing that is interesting to you to fix and order of magnitude how long things might take, I could consider that.  I think you have my email.


Laeeth

On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
> I like D, but sometimes it's look like for me too complicated. Go have a lot of fans even it not simple, but primitive. But some D futures make it very hard to learning.
>
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
>
> Which language futures by your opinion make D harder?

right now.. compile time function execution ;-)