>I remain to be convinced that this is possible.

Check out D language with default GC and the ongoing effort opt-in ownership model:

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

I think it would need to have a GC like Go’s that allows arbitrary interior pointers. Then most of the standard library could continue to take references, which would be allowed to point to GC or non-GC memory. There isn’t too much in the standard library that wants you to pass things to it to take ownership of that make sense to be shared. For example, the buffered reader structure wants ownership of the file it’s reading from, but it’s not like it’s going to make sense to read the same file descriptor at the same time it’s being read by the buffered reader.

I think the bigger problem is that GC pointers will have to work like Rust’s reference counted pointers do today, meaning you need to use mutexes, read-write locks, etc. to mutate anything behind them. Most shared-memory GC languages allow free data races on all member variables, and just provide unordered atomicity to prevent you from being able to cause a race that writes a bad pointer somewhere. Changing that would be a much stronger mismatch, and as long as that’s the case you’re still not going to be able to write Rust code like you would Java or C#.

The obvious solution is that the standard library would provide both options wherever appropriate, just like Rust has `borrow` and `borrow_mut`, `raw_entry` and `raw_entry_mut`, etc. You might be able to save some of this pain with some polymorphism, as some people suggest[0] for `&` and `&mut`, too.

It might also be a good idea to look at the standard library of Idris 2[1] — it has linear types and garbage collection, so it has many of the same issues you describe, and it also seems to solve them with duplication where necessary[2], at least sometimes.

[0]: https://github.com/rust-lang/rfcs/issues/414

[1]: https://github.com/idris-lang/Idris2/tree/master/libs/base

[2]: https://github.com/idris-lang/Idris2/blob/master/libs/base/D...

There would at least need to be some kind of interface of gc and non-gc methods. I would welcome any academic papers on this idea.

> If you make a language GC by default with opt-in ownership, what does your standard library look like?

I could see the opposite working out very well. Having a GC type you can box other types in.

https://github.com/Manishearth/rust-gc

Well, the idea would be that references and values alike could be marked to be excluded from the garbage collector and then used in a borrowed way. If you want to interface with the garbage collector, you have to do so in an explicit way. However, I have no idea how to do so.