October 25, 2021

On Wednesday, 20 October 2021 at 09:47:54 UTC, SealabJaster wrote:

>

Just for giggles, without pesky things like breaking changes; rational thinking, logical reasoning behind the changes, etc.

What interesting changes would you make to the language, and what could they possibly look like?

For me the top priority would be to make what D already has more robust and fix some really annoying bugs about delegates and member alias parameters like issue #5710 that was fixed and then reverted.

There are a lot of other "features" that are half finished or in "preview" and "experimental" forever that could be made stable too.

Sure, there are some features (e.g. tuples and destructuring) that I really want but ironing out what is already there is way more important for me. The issue I linked before was one that I discovered like 5m after trying out D and still bugs me out to this day.

October 25, 2021

On Monday, 25 October 2021 at 20:59:54 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 25 October 2021 at 20:41:25 UTC, Paul Backus wrote:

>

In other words, it makes code easier to reason about and concurrency bugs easier to isolate.

That remains to be seen? There is really nothing that prevents another thread from writing to something that @safe code has access to. So not sure how this is a better situation than C++ has...

Sure, there's nothing preventing @system code from causing undefined behavior. The difference is that in C++, all of your code is @system; in D, only some of it is.

October 25, 2021

On Monday, 25 October 2021 at 21:49:15 UTC, Paul Backus wrote:

>

Sure, there's nothing preventing @system code from causing undefined behavior. The difference is that in C++, all of your code is @system; in D, only some of it is.

Yes, that is true. I don't write a lot of multi-threaded code, but when I do I tend to keep that to a small set of files/data-structures. As such I am keeping a "@system" subset in my source. It isn't checked by a compiler, but I am not sure that makes a big difference as I tend to encapsulate the "@system" parts using abstractions.

So if there is any benefit to the current version of "shared" it has to come from interacting with libraries. But there is little protection there since libraries can put themselves into "@trusted" mode at their own will? So, then the remaining advantage would be to have the opportunity to grep for @system/@trusted in library code...

I am not convinced that this is enough to be a significant advantage as I am not inclined to use libraries that aren't well-behaved (if they are a source for bugs, I'll most likely replace them wholesale).

October 25, 2021

On Sunday, 24 October 2021 at 20:04:05 UTC, Paul Backus wrote:

>

On Sunday, 24 October 2021 at 19:47:10 UTC, Basile B. wrote:

>

I believe it's partly a problem of lazyness, e.g "I want to type less. I want to be proposed filter when I CTRL+SPACE after arr.fi ".

That case can be solved by doing a word split on the current document and by adding the results to the "good" completions when they are requested. If you have selective imports at the top of the module, for filter, map, each etc. then they are proposed as well.

Yeah, this is basically how Vim's built-in completion works. I sometimes use it to save typing on long identifiers, or to avoid spelling mistakes. But if I have to fall back to typing something out manually, it's not that big of a deal.

Maybe it's programmers who can't touch-type who rely heavily on tooling support? I know if I had to hunt-and-peck every letter of an identifier like formattedWrite, I'd be a lot more motivated to use code completion everywhere I could.

>

The other part of the problem is that completion can be used to overcome the lack of knowledge of an API, for example. In this case the word split does not help.

Yeah, in that situation having an easy way to view the docs is really helpful. I have a shortcut set up in Vim that opens the dpldocs.info search page with the identifier under the cursor, which works pretty well for the standard library and ok for dub packages, but a language server could probably do a better job.

I'm thinking to a new design lately.

The deamon would just keep the ast in sync and when a request is made the semantic is run from a particular point. The idea is that there's no need to run the sema for everything on each request.

We only need to have the AST up to date, undecorate it when a file changes, redecorate it when request are made. And important, only redecorate from what's asked.

October 25, 2021
On Mon, Oct 25, 2021 at 11:34:10PM +0000, Basile B. via Digitalmars-d wrote:
> On Sunday, 24 October 2021 at 20:04:05 UTC, Paul Backus wrote:
[...]
> > I have a shortcut set up in Vim that opens the [dpldocs.info][2] search page with the identifier under the cursor, which works pretty well for the standard library and ok for dub packages, but a language server could probably do a better job.
> > 
> > [2]: http://dpldocs.info/
> 
> I'm thinking to a new design lately.
> 
> The deamon would just keep the ast in sync and when a request is made the semantic is run from a particular point. The idea is that there's no need to run the sema for everything on each request.
> 
> We only need to have the AST up to date, undecorate it when a file changes, redecorate it when request are made. And important, only redecorate from what's asked.

The problem with this is that the current DMDFE mutates the AST as it goes along. So you either have to save a pristine copy of it somewhere in the server, somehow isolate and apply changes to it as you go along, and re-inject it into DMDFE (which according to Walter doesn't really improve performance that much), or you have to rewrite large swathes of the compiler to do its work without mutating the AST.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
October 25, 2021
On Mon, Oct 25, 2021 at 06:06:27PM +0000, Paul Backus via Digitalmars-d wrote:
> On Monday, 25 October 2021 at 17:45:22 UTC, H. S. Teoh wrote:
> > I suspect part of this problem is caused by the lame specialcased behaviour of template instantiation errors being ignored when it's opDispatch.  It's D's version of C++'s SFINAE, which leads to all sorts of stupidity like a typo inside opDispatch suddenly causing a dispatched member to disappear from existence 'cos the compiler swallows the error and pretends the member simply doesn't exist.  So if you're introspecting the member, the introspection code doesn't even see it.  Which leads to hours of head-scratching over "I obviously declared the darned member, why does the code NOT see it?!?!".
[...]
> It's actually worse than that. Errors inside `opDispatch` are gagged and cause member lookup to fail...*unless* they're nested inside *another* template, in which case member lookup will succeed, and you will only get the error when you try to actually access the member:
[...]
> It's special cases inside of special cases--a complete mess.

=-O

Wow, that's totally messed up. :-/  Yeah, if there's any way to fix this without breaking existing code, I'd love to push for this change in the language.  Not holding my breath for it, though, unfortunately.


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
October 26, 2021

On Monday, 25 October 2021 at 23:50:59 UTC, H. S. Teoh wrote:

>

On Mon, Oct 25, 2021 at 11:34:10PM +0000, Basile B. via Digitalmars-d wrote:

>

On Sunday, 24 October 2021 at 20:04:05 UTC, Paul Backus wrote:
[...]

>

I have a shortcut set up in Vim that opens the dpldocs.info search page with the identifier under the cursor, which works pretty well for the standard library and ok for dub packages, but a language server could probably do a better job.

I'm thinking to a new design lately.

The deamon would just keep the ast in sync and when a request is made the semantic is run from a particular point. The idea is that there's no need to run the sema for everything on each request.

We only need to have the AST up to date, undecorate it when a file changes, redecorate it when request are made. And important, only redecorate from what's asked.

The problem with this is that the current DMDFE mutates the AST as it goes along.

yeah indeed, aka lowerings...

October 25, 2021
On Tue, Oct 26, 2021 at 01:01:04AM +0000, Basile B. via Digitalmars-d wrote:
> On Monday, 25 October 2021 at 23:50:59 UTC, H. S. Teoh wrote:
> > On Mon, Oct 25, 2021 at 11:34:10PM +0000, Basile B. via Digitalmars-d wrote:
[...]
> > > We only need to have the AST up to date, undecorate it when a file changes, redecorate it when request are made. And important, only redecorate from what's asked.
> > 
> > The problem with this is that the current DMDFE mutates the AST as it goes along.
> 
> yeah indeed, aka lowerings...

But the thing is, lowerings don't *have* to be implemented as AST mutations. They can be a side-branch of the AST node for example. Or just translate to pure IR along with the rest of the code, then transformed as IR without touching the AST. It's more efficient (and less bug-prone) to transform IR than to meddle with the AST anyway.


T

-- 
Тише едешь, дальше будешь.
October 27, 2021

Remove the problems that make the GC slow. I know this cannot be done without breaking many things, but this topic is about expressing wishes, right? ;-)

October 27, 2021

On Monday, 25 October 2021 at 14:34:24 UTC, IGotD- wrote:

> >
  • pure

Agreed, if you don't want a function messing around with a global state, don't mess around with a global state, easy. You don't need a badge for that. I'm sure there are holes in the pure rule that the compiler cannot detect as well.

pure is also supposed to be an optimization aid. I was about to say that you're right about that holes thing, because of stuff like this one:

pure short coming()
{ typeof(return) result = void;
  return result; //may return anything
}

But when you think of it, why should this be a problem? This one returns an implementation defined value. If a compiler skips repeated calls to this one because of the pure attribute and just reuses the value from the first call, so what? Because the return values are implementation defined, the compiler is free to have them all to be the same with regards to each other.