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/bab72829-7c67-462e-917d-b6107449ba25n%40googlegroups.com.
