On Mon, Aug 18, 2025 at 9:49 PM Ruslan Semagin <pixel.365...@gmail.com> wrote:
> In general, it seems to me that much of the opposition here comes from a > general reluctance to introduce *any* new syntax into the language. > If I try to summarize the proposal clearly, it is nothing more than > syntactic sugar for a very specific case. > > This syntactic sugar: > 1. Does not complicate the language. > 2. Does not break backward compatibility. > 3. Leaves the choice to the programmer which form to use in a given > situation. > 4. Reduces boilerplate in places where the pattern occurs. > 5. Does not introduce new semantics or unexpected side effects—its > behavior is exactly that of the explicit loop. > 6. Can be fully and clearly documented in the language specification, as > with other small sugars. > > It is not a revolutionary change. It is simply an additional, optional way > of writing code in a specific situation. > One can easily write a generic function that does this: https://go.dev/play/p/kJRTuaOc5mV Adding more syntax to the language in order to handle a case that can be handled with a simple function call would seem to require a pretty strong reason. Also, forgive me if I missed it, but I do not see where you have addressed Dan Kortschak's point: how would your new syntax interact with select statements? -- 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 visit https://groups.google.com/d/msgid/golang-nuts/CAADvV_twKdhjW4EbSrktR%3Dh_XgY9FdGeWj37o1Rwf0eiaVJbMw%40mail.gmail.com.
