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 <[email protected]> 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 <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian <[email protected]>
>>>>>> 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 <
>>>>>>>> [email protected]> 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 <
>>>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>>>>> 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 [email protected].
>>>>>>>>>>> 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 [email protected].
>>>>>>>>>
>>>>>>>> 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 [email protected].
>>>>>>> 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
>>> [email protected].
>>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/85f808e8-6ae8-45d8-af23-394e65ee2425n%40googlegroups.com.
