"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.cand...@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+unsubscr...@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/CAB3gO8pC%2BRrTfwMwr4Yk2Tmw16EV%3DY7_rdMCXOK7GP-AZfmrgQ%40mail.gmail.com.

Reply via email to