Can signatures be made simpler and error messages be made better?

[sighoya]

On Saturday, 12 June 2021 at 11:29:59 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 12 June 2021 at 11:14:08 UTC, sighoya wrote:
>> Just to reiterate the essence: The general problem with static 
>> dependent typing is to track type (lifetime) state to make the 
>> lifetime constraints useful, otherwise you have hard times to 
>> auto prove your code given the life times constraints.
>
> Not really sure what you mean now. You would have to make the 
> constraints more limiting than needed, to get the verification 
> to pass. That is certain.

What I mean is that constrains are pointless if not static 
information was inferred.

> However, the basic idea would be to emit the high level IR, so 
> there is really no limit to what can be analyzed.

I'm not the fan of it, each IR is a cost.

> I don't think it should be opt-in. The code gen would optimize 
> based on the guarantees that are stated in the code. So the 
> verfication would run, but it could run delayed, then feed back 
> information to the IDE.

So we evaluate it anyways, then we have the same cost as in Rust?

> I think it should ship with the compiler, but I think it should 
> be a separate pass.

It doesn't matter who is responsible for, it is part of the 
compiler pipeline, so you have to wait for.

> Start thinking of D-tooling as a set of tools, not just DMD. So 
> you have DMD + verifier + IDE-server + IDE of you own choice.

This is a major undertaking for DMD, why not developing a 
separate IDE compile just as it is the case for Java, it is 
slower, fur sure, but it literally enables developing code faster.


> Maybe the mindset of Go and Rust teams are very conservative 
> and stuck in the past?

I think this is true regarding GC as the evil of efficiency :).