"<-chan TYPE" is the receive end, "chan<- TYPE" is the send end, "chan TYPE" without an arrow can be used for either.
close() on a chan is "indicate end-of-transmission"; you should only ever use it from the send end. There is no way to explicitly "close" the receive end.
You can use `select` to do a non-blocking sends/receives, but yeah normal sends/receives are blocking.
> "<-chan TYPE" is the receive end, "chan<- TYPE" is the send end, "chan TYPE" without an arrow can be used for either.
The problem is that there is pretty much just a subtyping relationship, when you convert a channel to a send or receive channel you don't get a different object, you just get the relevant subset of operations.
> There is no way to explicitly "close" the receive end.
And that's the root cause of half of more of the example issues in TFA. With the ability to close either end of the channel (and to handle closed receivers from the senders, obviously), most of the issues just go away (even more reliably so if that happens for you when the relevant end stops being used).
8" floppy drives were not compatible mechanically with IBM PC cases, but there were 8" floppy drives with their own enclosures and power supplies, which could be put on a desktop along the PC case.
IBM PCs have never supported 8" floppy drives, but it was easy to make an adapter between IBM PC floppy cables and 8" floppy drives, so there have existed IBM PC clones from countries where 5¼" floppies were scarce (e.g. Eastern Europe), which supported the attachment of 8" floppy drives.
The original 5¼" floppies had only the size advantage, but they had both a lower capacity and a lower speed than 8" floppies, so attaching 8" floppy drives would have been a higher performance option in the beginning.
Only after the IBM PC/AT introduced the high-density 1.2 Mbyte floppy disks, the 5¼" format matched (actually very slightly exceeded) the performance of the old 8" floppies.
It was not. It was implemented by Dylan Taylor, an outside contributor who works at a fintech company in North Carolina, and has made it his hobby to submit PRs implementing age verification to all kinds of projects. The systemd maintainer who clicked "merge" (Luca Boccassi) does work at Microsoft.
I would love to understand his motives, because my first impression is not a positive one. This is not freedom-loving behavior of a patriotic US citizen.
type IntBox struct { v int }
type StrBox struct { v string }
func (b IntBox) MapToStr(f func(int) string) StrBox {
return StrBox{v: f(b.v)}
}
(Please forgive any typos I made on mobile.)
It wasn't a great example because "Box" isn't really a useful type. But the point is that you no longer need to define a separate "MapToXXX" method for every type you might want to map to; now you can have just one type-generic "Map" method.
It is very close to one. My Option[T] type [1] cannot have a Map method in stable Go because of the type system restriction in question. Instead, I have a separate package with freestanding functions with the same purpose, including Map [2].
close() on a chan is "indicate end-of-transmission"; you should only ever use it from the send end. There is no way to explicitly "close" the receive end.
You can use `select` to do a non-blocking sends/receives, but yeah normal sends/receives are blocking.
reply