On Sat, Mar 23, 2024 at 12:20 PM Jeffery Carr <basilarc...@gmail.com> wrote: > > While doing that and looking at the code, there are lots of interesting and > good things in internal/ that can't be used. While I think I understand the > reasons for internal/, I wonder if the GO compiler might be more immune to > those normal reasons. In general: it's sage advice to never make the compiler > people unhappy. Usually then lots of strange things start not working! > > In that regard, s/internal/workshop/ would denote things not yet stable. The > compiler really only needing an example to demonstrate the usage
Our experience is that once something becomes publicly accessible, it becomes very difficult to change. It's already difficult to change runtime internal functions, because packages out there reach into the runtime using //go:linkname directives. This is clearly and obviously unsupported. Yet people do it. That forces us into the uncomfortable position of breaking existing working packages or advancing the runtime. It's not a great position to be in. That's why we have rules like internal packages that are difficult to break. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXOOtc-yacPu%3DcOVF9_jB9Ey38OowKHsyJFkX%3DtdoCpjg%40mail.gmail.com.
