Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Lots of languages are aiming for "like Rust, but easier to use" -- I think I could name half a dozen. It's a laudable goal!

I'm curious how references in your language work. I see the very small example, but it doesn't explain much.

Some questions in that regard: Is `&T` a type? Can you store it in a structure, or return it? Can you have a reference to a reference? If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument? If references can't be stored in structs, how do you do non-owned iterators, or string slices?



If you scroll past the code examples, there are a few more details, though for more you'll need to look at the documentation (specifically https://docs.inko-lang.org/manual/main/getting-started/memor...).

> Is `&T` a type?

Inko's syntax for references is `ref T` for immutable references/borrows, and `mut T` for mutable ones. Unlike Rust, you can't implement methods/traits _only_ for references, instead you can only implement them for the underlying "base" type. So `impl ToString for String { ... }` is valid, but `impl ToString for ref String { ... }` isn't.

> Can you store it in a structure, or return it?

Yes.

> Can you have a reference to a reference?

No, `ref ref T` is "collapsed" into just `ref T`, and the language has no notion of pointers and pointer-pointers.

> If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument

Inko doesn't have a borrow checker, so it doesn't. Instead it relies on runtime reference counting to prevent dropping of values that still have references to them. Over time I hope to implement more compile-time analysis to reduce this cost as much as possible, but borrow checking/lifetime analysis like Rust isn't something Inko will have.

Or to put it differently, I want the compiler to catch say 80-90% of the obvious "this ref outlives its pointee" errors without complicated borrow checkers. For the remaining 10-20% the runtime check should suffice.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: