The Go2 proposal process is open minded. Suggest that every well-considered
suggestion be made. Personally, I’m no fan of idiomatic as an argument, it
seems more of a consequence—like bare earth paths worn through grassy
parks—when the paved sidewalks are in the wrong place, the idiomatic path
goes off-road. When there are guardrails preventing that, the idiomatic
path is wrong, just the closest allowed fit. Go2 is the time to ignore the
rails.
I miss discriminated unions too. (Fancy new name, “sum types”). People like
enumerations. There are many odd to Go things that if added, would quickly
become second nature: letting += and * etc apply to arrays and slices would
be natural, smoothly integrate the myriad ugly named vector operations, and
make such code 2x, 4x, 8x faster. It would be a shame to hold back
suggesting it because “operators on non-primitive types are disallowed.”
Be bold. I’m saying this because in reading this thread I think my comment
about hard-won lessons may have come across wrong. It is not that Go is
perfect and should not be changed, more (to me) like Go’s omissions tend to
me much more strategic than people recognize, so the way to add the benefit
that’s missing is not usually to add the feature with that benefit from
other languages. That should motivate new ways, not shut down changes. But
those new ways require free thinking.
On Sun, Jun 9, 2019 at 1:00 PM Steven Blenkinsop <steven...@gmail.com>
wrote:
> If one library defines string.Render() for html, and another defines
>> another string.Render() for, say, a graphics library, which Render will be
>> called when I call "str".Render()?
>
>
> Method call syntax is the least of the worries. Presumably, that could be
> based on which packages are imported in the calling context, and you'd get
> an error if it's ambiguous. The larger problem is when you get interfaces
> involved. Two Content variables storing the same value of type string could
> have different implementations of Render depending on where the interface
> value was created. And if a variable v of type Content is used in a way
> equivalent to interface{}(v).(Content), you could end up changing the
> implementation of Render or failing the assertion altogether. So, the
> problem with allowing an arbitrary package to define methods on primitive
> types isn't with method call syntax, it's with using such methods to
> satisfy an interface like Content.
>
> One workaround would be to allow you to use package-qualified method
> names, so
>
> package foo
>
> type Content interface {
> package.Render()
> }
>
> func (s string) package.Render() { ... }
>
> At minimum, package-qualified methods defined in other packages couldn't
> be used to satisfy Content. Normal Render methods defined in other
> packages (for types which have to be defined in those packages) could be
> allowed to satisfy the interface, and/or other packages could be allowed to
> define methods like
>
> func (t T) foo.Render() { ... }
>
> for their own types to satisfy the interface.
>
> There hasn't been much interest in pursuing anything like this for Go,
> however. Something like the sum types mentioned by Bakul might be a better
> match for existing Go idioms, since it could be a swap-in replacement for
> interface{} in existing functions that use a type switch with an
> interface fallback, allowing them to better specify which types they
> support. Of course, there's also been opposition to adding sum types, since
> many see interfaces as "good enough" to cover the use cases of sum types.
>
> On Fri, Jun 7, 2019 at 3:00 PM Burak Serdar <bser...@ieee.org> wrote:
>
>> On Fri, Jun 7, 2019 at 12:40 PM Michael Ellis <michael.f.el...@gmail.com>
>> wrote:
>> >
>> > Count me among those who love the language just the way it is and
>> regard the prospect Go 2.0 with dread and loathing born of the Python 3
>> experience.
>> >
>> > That being said, there's one itty-bitty change I'd like to advocate:
>> Allow methods on primitives.
>> >
>> > I think I understand why allowing new methods on external packages is a
>> bad idea because it introduces a form of the fragile superclass problem.
>> But surely there's nothing fragile about strings, ints and floats.
>> >
>> > Being unable to define a method on a string is *not* a showstopper
>> since one can always do "type Foo string" or use type-assertions. It's just
>> that it's inelegant in the case of a function that takes a recursive struct
>> as an argument if the leaves of the tree are strings. For example
>> >
>> > type HTMLTree struct {
>> > tag string
>> > attributes string
>> > content * Content //
>> > }
>> >
>> > type Content interface {
>> > Render()
>> > }
>> >
>> > // NOT ALLOWED
>> > func (s string) Render() {
>> > }
>> >
>> > So I have to do something like
>> >
>> > type SC string
>> > func (s SC) Render() {
>> > }
>> >
>> > but that means instead of being able to write
>> >
>> > Div("", P("id=1", "When in the course of ..."))
>> >
>> > one must use the wrapper type on every content string.
>> >
>> > Div("", P("id=1", SC("When in the course of ...")))
>> >
>> > Not the end of the world, but uglier than it ought to be, IMO.
>> >
>> > Is there a way to get around this or, failing that, an explanation of
>> why methods on primitives are verboten?
>>
>> If one library defines string.Render() for html, and another defines
>> another string.Render() for, say, a graphics library, which Render
>> will be called when I call "str".Render()?
>>
>> >
>> > Thanks!
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > 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/6daa53b9-c2e6-48e8-b022-c8339d3b8dbc%40googlegroups.com
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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/CAMV2Rqo6vMmEOxTzp%2BB2AJXc-ZUuSpNP-7p0AYMoRd86-hR2Bg%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CANjmGJsfSYVtefWN7jxv7J1v607HWuMq6q5_KaZat0yfpbH%3DtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CANjmGJsfSYVtefWN7jxv7J1v607HWuMq6q5_KaZat0yfpbH%3DtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
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/CALoEmQxLC4DFFcYQDmok6na-p34KUAK%2BxPzZLwD2HOnCEQTFNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
