drink() takes a Drinkable. A Drinkables can be non-copyable.
Copyable is the default, so it has to mark itself as accepting non-copyables.
Coffee is non-copyable. Water doesn’t say which means it’s copyable (the default).
You can use a copyable anywhere you’d use a non-copyable since there is no restriction. So since drink can take non-copyables it can also use copyables.
I’m guessing the function definition has to list non-copyable otherwise it would only allow copyable drinks since the default is all variables are copyable.
“consuming some” means the function takes over the ownership of the non-copyable value. It’s no longer usable in the scope that calls drink().
For the copyable value I’m not sure but since they can be copied I could see that going either way.
On syntax:
Yeah it’s a bit weird, but there was a big debate about it. They wanted something easy to read and fast to use. NotCopyable<Drinkable> is really clear but typing it over and over would get real old.
~ is not special syntax. My understand is “~Copyable” is the name of the type. You can’t just put ~ in front of anything, like ~Drinkable. But since that’s the syntax used for bitwise negation it’s pretty guessable.
& is existing syntax for multiple type assertions. You can see the evolution in this Stack Overflow answer:
https://stackoverflow.com/a/24089278
Seems to read like C to me. It has to be Drinkable and not Copyable.
Like I said I haven’t gotten to use this yet, but it seems like a nice improvement. And I know it’s a step in the path towards making it easier to do safe asynchronous programming, object lifetimes, and other features.