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 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/60972fb6-0d9e-4d4f-bddd-1c83ff5d4516n%40googlegroups.com.
