s3 == []int{0, 0, 2, 3, 5, 7, 0, 0} Therefore, s3[3:6] is {3, 5, 7} // from index 3 up to but not including 6 s3[2:] is {2, 3, 5, 7, 0, 0} // from index 2 to end
Unless I'm missing something? On Wednesday, 2 August 2023 at 17:59:06 UTC+1 Kamil Ziemian wrote: > Hello, > > First, as I probably end my first reading of Go Spec in coming days, I > want to thank you all for helping me in that. Thank you. :) > > Second, I have question about example shown in section "Appending to and > copying slices". > > s0 := []int{0, 0} > s1 := append(s0, 2) // append a single element s1 == > []int{0, 0, 2} > s2 := append(s1, 3, 5, 7) // append multiple elements s2 == > []int{0, 0, 2, 3, 5, 7} > s3 := append(s2, s0...) // append a slice s3 == > []int{0, 0, 2, 3, 5, 7, 0, 0} > s4 := append(s3[3:6], s3[2:]...) // append overlapping slice s4 == > []int{3, 5, 7, 2, 3, 5, 7, 0, 0} > > I didn't understand why s4 looks that after append. I would guess that if > I call append(s3[3:6], s3[:2]...) (s3[2:] replaced by s3[:2]) it should > produce result above. But I don't think clearly recently, to much on my > head. > > Best regards, > Kamil > > sobota, 29 lipca 2023 o 19:50:51 UTC+2 Kamil Ziemian napisał(a): > >> "The confusion may come from the fact that a list of forbidden built-in >> operations is immediately followed by a list of (mostly) allowed operations >> that illustrate the original rule?" >> You hit the nail on the head. >> >> I don't have much faith in me as programmer, so I ask about any such >> issue that is bothering me. >> >> Best regards, >> Kamil >> >> pt., 28 lip 2023 o 17:32 Brian Candler <b.ca...@pobox.com> napisał(a): >> >>> If you wanted to be absolutely clear, you could insert "The following >>> are examples of expression statements" - although it didn't really trouble >>> me as-is. >>> >>> On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote: >>> >>>> The confusion may come from the fact that a list of forbidden built-in >>>> operations is immediately followed by a list of (mostly) allowed >>>> operations >>>> that illustrate the original rule? With the exception of "len", it may be >>>> more clear for it to be structure like: >>>> ExpressionStmt = Expression . >>>> >>>> h(x+y) >>>> f.Close() >>>> <-ch >>>> (<-ch) >>>> len("foo") // illegal if len is the built-in function >>>> >>>> The following built-in functions are not permitted in statement >>>> context: >>>> append cap complex imag len make new real >>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof >>>> unsafe.Slice >>>> >>>> But, that leaves the "len" example with zero context upfront. >>>> >>>> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote: >>>> >>>>> Note also, that you didn't paste the entire section: >>>>> >>>>> With the exception of specific built-in functions, function and method >>>>> calls and receive operations can appear in statement context. Such >>>>> statements may be parenthesized. […] The following built-in functions are >>>>> not permitted in statement context: >>>>> >>>>> This is IMO very clear about those other examples being allowed. >>>>> >>>>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner <axel.wa...@googlemail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian <kziem...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> After a long break, I go back to reading Go Spec. >>>>>>> >>>>>>> In the section "Expression statements" we read that "The following >>>>>>> built-in functions are not permitted in statement context: >>>>>>> >>>>>>> append cap complex imag len make new real >>>>>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice >>>>>>> >>>>>>> h(x+y) >>>>>>> f.Close() >>>>>>> <-ch >>>>>>> (<-ch) >>>>>>> len("foo") // illegal if len is the built-in function" >>>>>>> >>>>>>> Are things following "h(x+y)" also forbidden in the statement >>>>>>> context? This part of spec isn't specially clear in my opinion. >>>>>>> >>>>>> >>>>>> No, they are not. Otherwise, they'd have a comment following them >>>>>> saying "illegal for $reason". >>>>>> >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Kamil >>>>>>> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a): >>>>>>> >>>>>>>> Although the sentence is OK as it stands, the section should be >>>>>>>> tweaked a bit. One of the examples there (myString(0x65e5)) is valid >>>>>>>> Go but >>>>>>>> vet rejects it, as part of the move towards disallowing this >>>>>>>> conversion, >>>>>>>> which was there mostly for bootstrapping the libraries. >>>>>>>> >>>>>>>> -rob >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts < >>>>>>>> golan...@googlegroups.com> wrote: >>>>>>>> >>>>>>>>> Ah, the spec does actually say: >>>>>>>>>> >>>>>>>>>> Converting a signed or unsigned integer value to a string type >>>>>>>>>> yields a string containing the UTF-8 representation of the integer. >>>>>>>>>> Values >>>>>>>>>> outside the range of valid Unicode code points are converted to >>>>>>>>>> "\uFFFD". >>>>>>>>> >>>>>>>>> >>>>>>>>> Personally, I think this is fine as is. I think people understand >>>>>>>>> what happens from these two sentences. >>>>>>>>> >>>>>>>>> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner < >>>>>>>>> axel.wa...@googlemail.com> wrote: >>>>>>>>> >>>>>>>>>> I'm not entirely sure. I don't think your phrasing is correct, as >>>>>>>>>> it doesn't represent what happens if the integer value exceeds the >>>>>>>>>> range of >>>>>>>>>> valid codepoints (i.e. if it needs more than 32 bits to represent). >>>>>>>>>> That >>>>>>>>>> being said, the sentence as is also isn't really precise about it. >>>>>>>>>> From >>>>>>>>>> what I can tell, the result is not valid UTF-8 in any case. >>>>>>>>>> >>>>>>>>>> I think it might make sense to file an issue about this, though >>>>>>>>>> in general that conversion is deprecated anyway and gets flagged by >>>>>>>>>> `go >>>>>>>>>> vet` (and `go test`) because it is not what's usually expected. So >>>>>>>>>> I'm not >>>>>>>>>> sure how important it is to get this exactly right and >>>>>>>>>> understandable. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian <kziem...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I have some hair splitting question. In the "Conversions to and >>>>>>>>>>> from a string type" we read: >>>>>>>>>>> "Converting a signed or unsigned integer value to a string type >>>>>>>>>>> yields a string containing the UTF-8 representation of the integer." >>>>>>>>>>> >>>>>>>>>>> Would it be more corrected to say, that conversion from integer >>>>>>>>>>> to string gives you UTF-8 representation of code point described by >>>>>>>>>>> value >>>>>>>>>>> of the integer? Or maybe it is indeed representation of integer >>>>>>>>>>> described >>>>>>>>>>> by UTF-8 specification? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Kamil >>>>>>>>>>> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian >>>>>>>>>>> napisał(a): >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> From what I understand proper Gopher read at least one time >>>>>>>>>>>> "The Go Programming Language Specification" ( >>>>>>>>>>>> https://golang.org/ref/spec) and now I need to read it too. >>>>>>>>>>>> >>>>>>>>>>>> I learn something of Extended Backus-Naur Form to understand >>>>>>>>>>>> it, so if I say something stupid beyond belief, I hope you will >>>>>>>>>>>> forgive me. >>>>>>>>>>>> In the first part "Notation" ( >>>>>>>>>>>> https://golang.org/ref/spec#Notation) I believe that I >>>>>>>>>>>> understand meaning of all concepts except of "production_name". On >>>>>>>>>>>> one hand >>>>>>>>>>>> "production_name" means that it is name of the production, not >>>>>>>>>>>> rocket >>>>>>>>>>>> science here. On the other, after reading about EBNF I feel that I >>>>>>>>>>>> should >>>>>>>>>>>> have more information about it. Can you explain it to me? >>>>>>>>>>>> >>>>>>>>>>>> Again I'm new to EBNF, so maybe this is stupid question. >>>>>>>>>>>> >>>>>>>>>>>> Best >>>>>>>>>>>> Kamil >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>> 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...@googlegroups.com. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> 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...@googlegroups.com. >>>>>>>>> >>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHaG8bYNLvLERu0-ad57wpoWsiB%2BFC5asyKA7FH6%2BvgZw%40mail.gmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHaG8bYNLvLERu0-ad57wpoWsiB%2BFC5asyKA7FH6%2BvgZw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>> 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...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/golang-nuts/a2031526-c215-4594-8da3-2aea38d95d85n%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/golang-nuts/a2031526-c215-4594-8da3-2aea38d95d85n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>> >> You received this message because you are subscribed to a topic in the >>> Google Groups "golang-nuts" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/golang-nuts/xwavrjBZbeE/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> golang-nuts...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/e730ee30-0a9e-4be9-9fee-08ed73d32b89n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/e730ee30-0a9e-4be9-9fee-08ed73d32b89n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/85f808e8-6ae8-45d8-af23-394e65ee2425n%40googlegroups.com.