You're not missing anything. The example is correct and helpful. It's also
something that can be tested out, for definite confirmation
<https://go.dev/play/p/KedJPb2xPYv>.
On Wed, Aug 2, 2023 at 9:57 PM Brian Candler <b.cand...@pobox.com> wrote:
> 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
> <https://groups.google.com/d/msgid/golang-nuts/85f808e8-6ae8-45d8-af23-394e65ee2425n%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/CAEkBMfFARzmc-iry4f58TWx4ejmwk0Uk4MXm5m15djXqwoMEqg%40mail.gmail.com.
