And I did not mean this to be a language feature. Just a tool - or part of
linter.
On Monday, February 12, 2018 at 11:36:36 PM UTC+3:30, dc0d wrote:
>
> Awesome!
>
> (IMHO)
>
> Going for total immutability is not a best fit for Go. I was thinking like
> excluding packages like unsafe, reflect,
Awesome!
(IMHO)
Going for total immutability is not a best fit for Go. I was thinking like
excluding packages like unsafe, reflect, executing external programs and
the like.
Capabilities seems unnecessarily complicated - getting used to them is not
easy, like in Pony/ponylang.
Thanks for
Only in the context of imported packages and only in terms of causing
side-effects "outside" the context of current executable binary.
On Monday, February 12, 2018 at 11:19:13 PM UTC+3:30, Paul Brousseau wrote:
>
> I think that might depend on what qualities you define as "safe"?
>
>
> On
We’ve been discussing stateless packages here:
https://github.com/golang/go/issues/23267
Matt
On Monday, February 12, 2018 at 1:43:05 PM UTC-6, dc0d wrote:
>
> Is there a way to identify a package as safe?
>
> Let's restrict the imported packages to built-in ones. Now assuming a
> package only
I think that might depend on what qualities you define as "safe"?
On Monday, February 12, 2018 at 12:43:05 PM UTC-7, dc0d wrote:
>
> Is there a way to identify a package as safe?
>
> Let's restrict the imported packages to built-in ones. Now assuming a
> package only imports "strings" and
