On Thu, 7 Nov 2019 02:58:17 -0800 (PST)
bsr wrote:
> Is there a way I can prevent this behavior.
> I am using Status like an enum, and only predefined status values should be
> allowed.
You cannot statically prevent someone from willfully assigning
to a variable of accessible type (eg. a
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 wrote:
> Hi Speter,
>
> Can you elaborate more
...job for a getter function.
On Fri, Nov 8, 2019 at 9:31 AM Jake Montgomery wrote:
> The inability to have a type safe enum in Go has bothered me as well.
>
> While using a struct, as Peter suggests, does prevent accidental use of
> literals, it also prevents you from making your enum items
The inability to have a type safe enum in Go has bothered me as well.
While using a struct, as Peter suggests, does prevent accidental use of
literals, it also prevents you from making your enum items constant.This
means that the values can be changed, accidentally, or intentionally, in
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 wrote:
> Hi bsr,
>
> I'd suggest to use a struct type with a single string field. It will
> prevent
Thanks Jan & Peter. I would use one of the approaches.
On Thursday, November 7, 2019 at 8:15:20 AM UTC-5, speter 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
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
On Thu, Nov 7, 2019 at 11:58 AM bsr wrote:
> Is there a way I can prevent this behavior.
Yes, if the rules for untyped literals are not wanted, make the
literal typed: https://play.golang.org/p/-f75y0Gb1Is
--
You received this message because you are subscribed to the Google Groups
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
