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

Paulo Pinto pjmlp at progtools.org
Sat Jun 12 11:35:58 UTC 2021


On Saturday, 12 June 2021 at 10:38:52 UTC, sighoya wrote:
> On Saturday, 12 June 2021 at 08:13:42 UTC, Ola Fosheim Grøstad 
> wrote:
>>```
>> int myfunc(A a, B b, ref T c)
>> require(£return==£a.x)
>> {
>>   body
>> }
>> ```
>
> Why not just reusing what we have?:
>
> ```D
> int myfunc(A a, B b, ref T c) if c.lt == retval.lt
> ```
>
> Lifetime tracking is already some form of static dependent 
> typing, and to be useable, it requires to introduce some type 
> state to work for that.
> In Rust, lifetimes are inferred all the time, and the inferred 
> lifetimes are propagated to infer new lifetimes.
> Rust exhibits this property from the beginning on, don't know 
> if this is possible for language to do afterwards, another 
> downside is that type state, in special lifetime state, takes 
> additional burden to the compiler.
> Solving inequalities may be harder than simple polynomial 
> constraint evaluation (disregarding custom computations), just 
> as it is the case for the current if section?
>
> I think this is part of the reason why Rust compiles slow.
>
> To be useful, such constraints have to be preserved in ABI, 
> otherwise you end up with the same problems as in Rust.
>
> Here is a link to Ralf's Thesis: 
> https://people.mpi-sws.org/~jung/phd/thesis-screen.pdf
>
> I've never read it, but it describes how lifetimes work, at 
> least I saw a chapter about it.

Rust slowness is mostly due to LLVM, with another backends like 
cranelift and using lld it is considerably faster.

They are also in the process of moving lifetime resolution engine 
to a Datalog based one, something that D most likely will never 
do,


http://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based-formulation-of-the-borrow-checker/






More information about the Digitalmars-d mailing list