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 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/e730ee30-0a9e-4be9-9fee-08ed73d32b89n%40googlegroups.com.
