On Mon, Jun 10, 2019 at 9:10 AM Jesper Louis Andersen
wrote:
>
>
>
> On Mon, Jun 10, 2019 at 1:34 PM Jan Mercl <0xj...@gmail.com> wrote:
>>
>>
>>
>> On Mon, Jun 10, 2019, 13:07 Jesper Louis Andersen
>> wrote:
>>>
>>> At some point, it is going to be "generally accepted" at which point
>>>
On Mon, Jun 10, 2019 at 1:34 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>
> On Mon, Jun 10, 2019, 13:07 Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
>> At some point, it is going to be "generally accepted" at which point
>> languages without sum types are going to be regarded
On Mon, Jun 10, 2019, 13:07 Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:
> At some point, it is going to be "generally accepted" at which point
> languages without sum types are going to be regarded as a relic of the
> past.
>
I hope to be dead for a long time then.
Don't get
On Mon, Jun 10, 2019 at 8:11 AM Michael Jones
wrote:
> I miss discriminated unions too. (Fancy new name, “sum types”).
>
They are called sum types because they work as an "addition" like
construction in the type theory. Their dual, product types, are what people
usually call records or structs
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
>
> 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
*type Content = Content_ | string*
That's a nice notation (and semantic). It certainly makes sense for this
case. Count me as a vote in favor.
*“I want you to act as if the house was on fire. Because it is.” — Greta
Thunberg*
On Sun, Jun 9, 2019 at 1:37 PM Bakul Shah wrote:
> On Jun 9,
On Jun 9, 2019, at 7:42 AM, Michael Ellis wrote:
>
> On Sunday, June 9, 2019 at 9:56:43 AM UTC-4, Bakul Shah wrote:
>
> You are almost always going to call a string's Render function
> (as you defined it in your original post) from a parent HTMLTree
> struct' Render(), almost never in
On Sun, Jun 9, 2019 at 8:42 AM Michael Ellis wrote:
>
>
>
> On Sunday, June 9, 2019 at 9:56:43 AM UTC-4, Bakul Shah wrote:
>>
>>
>> You are almost always going to call a string's Render function
>> (as you defined it in your original post) from a parent HTMLTree
>> struct' Render(), almost never
On Sunday, June 9, 2019 at 9:56:43 AM UTC-4, Bakul Shah wrote:
>
>
> You are almost always going to call a string's Render function
> (as you defined it in your original post) from a parent HTMLTree
> struct' Render(), almost never in isolation -- except perhaps some
> tests. So one
On Jun 9, 2019, at 6:14 AM, Michael Ellis wrote:
>
> I'm not disputing the wisdom of Go's design. As I said at the top of the
> initial post, I like Go the way it is and see no need for a Go 2.
>
> I was trying to find a clean solution to a specific use case: nestable
> functions that
I'm not disputing the wisdom of Go's design. As I said at the top of the
initial post, I like Go the way it is and see no need for a Go 2.
I was trying to find a clean solution to a specific use case: nestable
functions that generate html. Since new methods on primitives are not
allowed
To emphasize the wisdom:
With an implicit conversion like you mentioned, the F(x) invocation at
the bottom expects B.SomeFunc() will be called but in fact,
A.SomeFunc() will be called. That's why this is an error. You can
still do F(A(x)), which explicitly makes a copy of x as an A.
This is not
On Sat, Jun 8, 2019 at 3:22 PM Michael Ellis wrote:
>
>
> On Friday, June 7, 2019 at 3:01:04 PM UTC-4, Burak Serdar 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
On Sat, 8 Jun 2019 17:25:11 -0400
Michael Ellis wrote:
> Oops, got that the wrong way round. Should read "allow passing a Bar for
> argument of type Foo".
type Foo int
type Bar = Foo
func main() {
var fo Foo = 1
var ba Bar = 77
upbar(fo, "Foo")
upbar(ba, "Bar")
Oops, got that the wrong way round. Should read "allow passing a Bar for
argument of type Foo".
Cheers,
Mike
*“I want you to act as if the house was on fire. Because it is.” — Greta
Thunberg*
On Sat, Jun 8, 2019 at 5:22 PM Michael Ellis
wrote:
>
> On Friday, June 7, 2019 at 3:01:04 PM UTC-4,
On Friday, June 7, 2019 at 3:01:04 PM UTC-4, Burak Serdar 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()?
>
> Thanks for the explanation. That
On Fri, Jun 7, 2019 at 12:40 PM Michael Ellis 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
>
18 matches
Mail list logo
