Hi Mohamed,

The memory layout of "string" is the same as that of "struct { string }",
so there is no extra allocation or indirection involved on creation and
access, hence no runtime overhead.

Peter

On Fri, Nov 8, 2019 at 2:01 AM Mohamed Yousif <mmbu...@gmail.com> wrote:

> Hi Speter,
>
> Can you elaborate more on this point please?
> > there is no memory or runtime overhead due to encapsulating the string
> within a struct.
>
>
> On Thu, 7 Nov 2019 at 3:15 PM, speter <speter....@gmail.com> wrote:
>
>> Hi bsr,
>>
>> I'd suggest to use a struct type with a single string field. It will
>> prevent conversion from untyped string constant "by mistake".
>> Moreover, if you make the string field unexported, you can limit new
>> instance creation to the declaring package, allowing to enforce predefined
>> values.
>> Unlike with some other languages, there is no memory or runtime overhead
>> due to encapsulating the string within a struct.
>>
>> HTH,
>> Peter
>>
>> On Thu, Nov 7, 2019 at 7:58 PM bsr <bsr...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am a long time user of go, but I always had the impression that below
>>> code would not work as string and Status are different type.
>>> I thought I need to explicitly convert as ```exec(Status("abc"))``` it
>>> to work.
>>>
>>> I think, this part of the spec may be the reason
>>> https://golang.org/ref/spec#Assignability
>>>
>>>    - x is an untyped constant <https://golang.org/ref/spec#Constants>
>>>    representable <https://golang.org/ref/spec#Representability> by a
>>>    value of type T.
>>>
>>> Is there a way I can prevent this behavior.
>>> I am using Status like an enum, and only predefined status values should
>>> be allowed.
>>>
>>>
>>>
>>>
>>> https://play.golang.org/p/4zsb7KtPBC6
>>>
>>> package main
>>>
>>> import (
>>>     "fmt"
>>> )
>>>
>>> type Status string
>>>
>>> func main() {
>>>     exec("abc")
>>> }
>>>
>>> func exec(s Status) {
>>>     fmt.Printf("Hello, %s", s)
>>> }
>>>
>>> --
>>> 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/a20a7034-19c3-410a-bc86-25deff38534f%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/a20a7034-19c3-410a-bc86-25deff38534f%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/CAK_MaNuSTSGGummC5cOyh%2BbR9VCovrX3xHamDLixDUWbk010Dw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAK_MaNuSTSGGummC5cOyh%2BbR9VCovrX3xHamDLixDUWbk010Dw%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK_MaNsozfO1_emE4LzkuRYxF9TyBQA1S%2B%2BJh2rN%2B310iv0T%2Bg%40mail.gmail.com.

Reply via email to