date:20181018

On Thu, Oct 18, 2018 at 10:37 PM Rusco  wrote:
>
> I just tried this Google Playground recipe from Bradfritz:
>
> https://play.golang.org/p/RYac90kI-H
>
> (seen via https://github.com/golang/go/issues/21095)
>
> and noted that y appears in the output but x appears as .
>
> Can someone explain me why ? I was expecting that x appears in the same way 
> like y.

It is because of the NaN in the struct. NaN==x is always false for all
x, so NaN containing instances of S are not equal even though all the
non-NaN members are equal. Duplicate the line that adds "x", and set
it to "z", and you'll have three elements in the map, two of which
with identical keys and nil value.

>
>
> package main
>
> import (
> "fmt"
> "math"
> )
>
> var a, b int
>
> func main() {
> type S struct {
> x int16
> y float64
> z interface{}
> p *int
> }
> m := map[S]string{}
> m[S{1, math.NaN(), "foo", &a}] = "x"
> m[S{2, 3.0, &a, &b}] = "y"
> for i := 0; i < 20; i++ {
> fmt.Printf("%+v\n", m)
> }
> }
>
> //output:
>
> map[{x:2 y:3 z:0x1b5400 p:0x1b5404}:y {x:1 y:NaN z:foo p:0x1b5400}:]
> map[{x:1 y:NaN z:foo p:0x1b5400}: {x:2 y:3 z:0x1b5400 p:0x1b5404}:y]
>
>
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Question about fmt.Printf of maps

2018-10-18 Thread Rusco

I just tried this Google Playground recipe from Bradfritz:

https://play.golang.org/p/RYac90kI-H

(seen via https://github.com/golang/go/issues/21095)

and noted that y appears in the output but x appears as .

Can someone explain me why ? I was expecting that x appears in the same way 
like y.


package main

import (
"fmt"
"math"
)

var a, b int

func main() {
type S struct {
x int16
y float64
z interface{}
p *int
}
m := map[S]string{}
m[S{1, math.NaN(), "foo", &a}] = "x"
m[S{2, 3.0, &a, &b}] = "y"
for i := 0; i < 20; i++ {
fmt.Printf("%+v\n", m)
}
}

//output:

map[{x:2 y:3 z:0x1b5400 p:0x1b5404}:y {x:1 y:NaN z:foo p:0x1b5400}:]
map[{x:1 y:NaN z:foo p:0x1b5400}: {x:2 y:3 z:0x1b5400 p:0x1b5404}:y]



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

2018-10-18 Thread Tamás Gulácsi

Providing a plugin (I prefer a separate binary called through rpc, but the 
native .so is ok, too) is not a solution?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Are there plans to add Encrypted SNI to crypto/tls?

2018-10-18 Thread Jaime


References

   - RFC https://tools.ietf.org/html/draft-rescorla-tls-esni-00
   - https://blog.cloudflare.com/esni/
   - https://www.cloudflare.com/ssl/encrypted-sni/
   - 
   
https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/
   

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go language should become an ANSI and ISO standard.

2018-10-18 Thread andrey mirtchovski

> JavaScript needs a standard - there are many implementations and browsers. 
> For the moment, there is only one Go, and I like that.

one go, but two reference implementation. any other implementation is
expected to conscribe to the spec.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go language should become an ANSI and ISO standard.

2018-10-18 Thread ancientlore

The purpose of a standard, in my opinion, is to allow multiple 
implementations to be compatible. This seems counter to the open-source 
model, where there is a reference implementation completely in the open 
that encourages community participation and improvement.

JavaScript needs a standard - there are many implementations and browsers. 
For the moment, there is only one Go, and I like that.

Mike

On Wednesday, October 17, 2018 at 11:41:36 AM UTC-4, Scott Cotton wrote:
>
> I think standards have a tendency to end up failing to be standard because 
> of a plethora of standards, the need to make optional parts which render 
> the standard impractical for basic tasks (eg open al), the fact that large 
> market interests tend to have their own version (eg open SL ES android), 
> etc.
>
> Small teams can make inspiring designs, such as Go.
>
> That said, Go lacks standardisation of the memory model and runtime. 
>  These render the qualitative semantic of the language unspecified.  To 
> date, in my opinion, this is a good thing because it has allowed decision 
> to evolve and be driven by use.
>
> However, I think now many of us would welcome steps towards specifications 
> of the memory model and runtime.  Full specifications would require a lot 
> of diverse expertise, coordination, and effort.
>
> If enough people are interested in contributing to that, maybe a SIG or 
> two would provide an opportunity for small yet diverse teams to start to 
> make progress, maybe incrementally specifying these things over time rather 
> than  a formal standards committee imposing full specifications would be 
> more practical.  I would be interested in following that.
>  
>
> On Wednesday, 10 October 2018 18:48:57 UTC+2, Michael Jones wrote:
>>
>> I was the engineering director for OpenGL’s birth and growth at SGI and 
>> have perspective on that process, and was for a long time a board member of 
>> the Open Geospatial Consortium (OGC) and have views from those ISO-related 
>> adventures. 
>>
>> I’m with Ian on this—I quite deeply respect standards but see them best 
>> as “recognition of standard practice” rather than “political arena to fight 
>> out new ideas.” The political aspect is not evil, it is simply 
>> acknowledgement of the need to respect diverse stakeholders; but what is 
>> bad about it, technically, is that the path finding of a small inspired 
>> team easily gets lost in the chorus of multitudes wanting everything.
>>
>> In UNIX you had a small inspired team. In almost every really great, 
>> lasting technology you have <= 20 people, often <= 2, who are making the 
>> contentious decisions. That is a critical number. The smallness allows a 
>> cohesive thought process, which allows spirit and flow. Big groupthink 
>> tends the other way, often with better individual decisions but with ideas 
>> that seem almost randomly distributed across the design space.  
>>
>> I would vote to standardize Go 1 when Go 2 is out. 
>>
>> On Wed, Oct 10, 2018 at 8:16 AM Ian Lance Taylor  
>> wrote:
>>
>>> On Wed, Oct 10, 2018 at 7:55 AM, Beoran  wrote:
>>> >
>>> > In certain environments, such as for government contracting in certain 
>>> countries, or for certain large corporations, or for developing safety 
>>> critical applications using certain international standards, only 
>>> programming languages that are officially standardized may be used. While 
>>> Go would be an excellent language for such government or safety critical 
>>> applications, it's acceptance is hampered due to the lack of an official 
>>> standard.
>>> >
>>> > While this is in essence a formality, which would entail submitting 
>>> the current Go language specification with the ANSI, and then have it 
>>> propagate to the ISO, I do appreciate that will take quite some time and 
>>> effort. But to further the acceptance of Go language, I would propose that 
>>> Google invests the necessary resources to make this happen, with support 
>>> from the community to edit the standard document if needed.
>>> >
>>> > The standard should probably be based on Go 1, since Go 2 is still 
>>> largely undecided and probably 5 years in the future.
>>> >
>>> > If you are worried about using Go for safety critical applications 
>>> consider this: it is rare that the compiler builder gives any safety 
>>> warranty, although there are some safety certified C compilers. But for 
>>> similar certified Go compilers to be developed, we need an official 
>>> standard first.
>>> >
>>> > Even if the compiler is not certified, you can still use it if you 
>>> validate it yourself. This implementation of go has extensive unit tests 
>>> which simplifies such validation a lot.
>>> >
>>> > I know of some safety critical software that is implemented in C and 
>>> compiled with GCC. As a language, Go is far safer than that, and that is 
>>> also why we need a standard, to be able to get away from C for some safety 
>>> applications.
>>>
>>> There are significant disadvantag

Re: [go-nuts] Re: do you use binary-only packages?

2018-10-18 Thread Tharaneedharan Vilwanathan

Hi Ian,

Good question. I don't have an answer.

But this raises some questions:

Should Go be anticipating many such possibilities today and tomorrow? Or
shut them off?

With this limitation, doesn't it look like Go is best suited for building
end products or service but one cannot build on top of some other's work
(with direct API access) without having access to source code? Are we
indirectly making Go well suited for (a) building end products or service
(as mentioned above) or (b) specific areas (typically research, education,
non-commercial) where we can create building blocks inside/outside the
company and the code will be shared as well.

One problem I see is we have a better chance of knowing who adopted Go for
what but not quite on who could not adopt for what reason.

Regards
dharani

On Thu, Oct 18, 2018 at 4:28 PM Ian Lance Taylor  wrote:

> On Thu, Oct 18, 2018 at 4:02 PM, Tharaneedharan Vilwanathan
>  wrote:
> >
> > This means source-code is the only way to share the work. When it
> companies
> > to sharing/selling their work on top of which others can build their
> > app/solution, this won't work. Doesn't this seem like a big restriction?
> > Particularly, computer industry being heavily dependent on IP rights (and
> > where trust is low)? Wouldn't this deter such companies from adopting Go?
> > For contrast, I have heard of providing binary only distribution even
> within
> > the same company.
>
> The question is: is anybody actually doing this?  Is anybody seriously
> thinking about it?
>
> Ian
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

2018-10-18 Thread ancientlore

In the past (C/C++ days) we used a lot of third-party binary-only packages 
like SmartHeap for memory management and LeadTools for imaging. (I like to 
think of that as the "Programmer's Paradise" era.) I haven't used 
binary-only packages in many years, but I do wonder how a company like 
LeadTools might make their offering available to Go developers. Presumably, 
they don't want to release their source code. It might be informative to 
get the opinions of companies like that.

Mike

On Thursday, October 18, 2018 at 7:28:23 PM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Oct 18, 2018 at 4:02 PM, Tharaneedharan Vilwanathan 
> > wrote: 
> > 
> > This means source-code is the only way to share the work. When it 
> companies 
> > to sharing/selling their work on top of which others can build their 
> > app/solution, this won't work. Doesn't this seem like a big restriction? 
> > Particularly, computer industry being heavily dependent on IP rights 
> (and 
> > where trust is low)? Wouldn't this deter such companies from adopting 
> Go? 
> > For contrast, I have heard of providing binary only distribution even 
> within 
> > the same company. 
>
> The question is: is anybody actually doing this?  Is anybody seriously 
> thinking about it? 
>
> Ian 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

On Thu, Oct 18, 2018 at 4:02 PM, Tharaneedharan Vilwanathan
 wrote:
>
> This means source-code is the only way to share the work. When it companies
> to sharing/selling their work on top of which others can build their
> app/solution, this won't work. Doesn't this seem like a big restriction?
> Particularly, computer industry being heavily dependent on IP rights (and
> where trust is low)? Wouldn't this deter such companies from adopting Go?
> For contrast, I have heard of providing binary only distribution even within
> the same company.

The question is: is anybody actually doing this?  Is anybody seriously
thinking about it?

Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

2018-10-18 Thread Tharaneedharan Vilwanathan

Hi Ian,

Thanks for the clarification!

This means source-code is the only way to share the work. When it companies
to sharing/selling their work on top of which others can build their
app/solution, this won't work. Doesn't this seem like a big restriction?
Particularly, computer industry being heavily dependent on IP rights (and
where trust is low)? Wouldn't this deter such companies from adopting Go?
For contrast, I have heard of providing binary only distribution even
within the same company.

Just thinking aloud.

Regards
dharani

On Thu, Oct 18, 2018 at 3:46 PM Ian Lance Taylor  wrote:

> On Thu, Oct 18, 2018 at 2:20 PM, Tharaneedharan Vilwanathan
>  wrote:
> >
> > If this happens, by design, Go will not allow, say, a middleware company
> to
> > provide binary only distribution?
>
> Yes.  There would be no way to for a company to provide a binary-only
> package to its users.  They would have to provide source code.
>
> Ian
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

On Thu, Oct 18, 2018 at 2:20 PM, Tharaneedharan Vilwanathan
 wrote:
>
> If this happens, by design, Go will not allow, say, a middleware company to
> provide binary only distribution?

Yes.  There would be no way to for a company to provide a binary-only
package to its users.  They would have to provide source code.

Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [gomobile] How to generate reverse-bindings for Java without the gradle-plugin?

2018-10-18 Thread Elias Naur

Does

gomobile bind 

work? If not, what does it say?

 - elias

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

2018-10-18 Thread Tharaneedharan Vilwanathan

Hi All,

I have a quick question. I hope I am not off topic.

If this happens, by design, Go will not allow, say, a middleware company to
provide binary only distribution?

Regards
dharani


On Thu, Oct 18, 2018 at 1:15 PM Ian Lance Taylor  wrote:

> On Thu, Oct 18, 2018 at 1:10 PM, Andrey Tcherepanov
>  wrote:
> >
> > Would replacement of "pure"
> > compiled-and-ready-to-be-linked  library packaging with just compiled and
> > compressed AST (probably lightly optimized) be a better solution?
>
> Thanks.  It's a fine approach but it's a considerable amount of design
> and implementation, and it's not completely clear it's possible at
> all.  If someone wants to make implementing such a scheme a
> longer-term goal, that would be interesting.  But discussing that will
> distract us from Russ's question, which is: should we continue to
> support binary packages approximately as they exist today?
>
> Ian
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 2:02 PM Ian Denhardt  wrote:
>
> Quoting robert engels (2018-10-18 15:22:36)
> > Can you explain this a bit more, I must be missing something. Using the 
> > example:
> >
> > func F(a,b type T like(int,X)) {
> >   if a > ...
> >   }
> > }
> >
> > How do you pass a struct to F because < isn’t valid on structs ???
> >
> > Which is why I proposed that < maps to Less() and then the primitives 
> > simplicity implement these various methods, and user defined structs MIGHT.
> >
> > That way you write the code using Less(), and it works with primitives as 
> > well.
>
> This is what I was getting at; simply making the operators correspond to
> methods is a well-known and fairly straightforward solution to the
> problem, and it seems like the idea proposed in this thread is much more
> complex.
>
> Once you allow operators to simply correspond to methods, you can just
> worry about how to abstract over methods, which you can do with
> interfaces. My proposal outlines a variant of this that is fairly
> simple, yet (once adding something like operator overloading) is still
> able to handle every single example in the draft.
>
> You can either give the primitive types methods, or allow methods to
> override operators; both approaches work.
>
> Burak, apologies if I've misinterpreted your own line of thinking.

You did not misinterpret what I said. I agree that your proposal is
quite similar to mine.

One crucial difference between the two is, I think, my line of
thinking is based on templates, and yours is on interfaces. So using
my approach, you can require that a type contains certain members, not
just methods. I don't know how important that is, but after working
with Java for many years, I developed a strong dislike for
getter/setters.

>
> -Ian
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

On Thu, Oct 18, 2018 at 1:10 PM, Andrey Tcherepanov
 wrote:
>
> Would replacement of "pure"
> compiled-and-ready-to-be-linked  library packaging with just compiled and
> compressed AST (probably lightly optimized) be a better solution?

Thanks.  It's a fine approach but it's a considerable amount of design
and implementation, and it's not completely clear it's possible at
all.  If someone wants to make implementing such a scheme a
longer-term goal, that would be interesting.  But discussing that will
distract us from Russ's question, which is: should we continue to
support binary packages approximately as they exist today?

Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: do you use binary-only packages?

2018-10-18 Thread Andrey Tcherepanov

Hello,

I have to agree that binary packages In the current form are not very 
useful, at least to us. We have played with an idea of having sqlite (C + a 
Go wrapper on top) wrapped up into a binary package, so we can continue to 
build multiple platforms from a single build machine. As result of 
investigation, that deemed to have more hassle than to have all platforms 
built separately even with pains of CGO involved.

IMHO, precompiled (pre-built) libraries are nice to have, be that 
"platform-dependent binary package" or some platform-agnostic jar file. I 
think a success of Java as a platform in no small part could be attributed 
to the fact that jar's are so easy to create, distribute and use (minus 
obvious dependency hell that we all have to go through periodically).

So far what I can think of

   - There are places that cannot distribute a library in source code 
   format, but would like to distribute a library.
   - Pre-built packages can be used to reduce build time (not sure how 
   important this is with 1.10+ cache)
   - Distribution of signed packages? I think it is not easy thing to do 
   with "just" a source code, unless it comes in a bundled form like a signed 
   zip file...
   
Thinking a bit about "richness of meta-info" vs "cannot distribute source 
code" and how Java and .NET are doing this... Would replacement of "pure" 
compiled-and-ready-to-be-linked  library packaging with just compiled and 
compressed AST (probably lightly optimized) be a better solution? 

This would give 

   1. a rich (full?) meta info for optimization
   2. a way to distribute code without source code for people who have to 
   do it that way.
   3. a bit of platform independence if all of suffixed files 
   ("*_windows.go" , "*_linux.go" etc) are parsed in.
   
I think it would also give some Go version independence, covering cases 
when library was built with older tools, but needs to be assembled with a 
newer Go distribution. This might work if...

   1. AST is a version independent (sorry, I don't know if it is), 
   2. AST is platform-agnostic
   3. has a forward compatible format or tools reading it are easy to make 
   backward-compatible

I am probably missing something obvious here (I don't think I am the first 
one to think about it, and I am in no way a language expert), but wanted to 
share this idea.

Thanks,
   Andrey

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Ian Denhardt

Quoting robert engels (2018-10-18 15:22:36)
> Can you explain this a bit more, I must be missing something. Using the 
> example:
>
> func F(a,b type T like(int,X)) {
>   if a ...
>   }
> }
>
> How do you pass a struct to F because < isn’t valid on structs ???
>
> Which is why I proposed that < maps to Less() and then the primitives 
> simplicity implement these various methods, and user defined structs MIGHT.
>
> That way you write the code using Less(), and it works with primitives as 
> well.

This is what I was getting at; simply making the operators correspond to
methods is a well-known and fairly straightforward solution to the
problem, and it seems like the idea proposed in this thread is much more
complex.

Once you allow operators to simply correspond to methods, you can just
worry about how to abstract over methods, which you can do with
interfaces. My proposal outlines a variant of this that is fairly
simple, yet (once adding something like operator overloading) is still
able to handle every single example in the draft.

You can either give the primitive types methods, or allow methods to
override operators; both approaches work.

Burak, apologies if I've misinterpreted your own line of thinking.

-Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

Sorry, it is confusing… because then someone chimes in and says ‘no’ to 
operator overloading which would make that impossible, which makes the example 
impossible for arbitrary X.

I guess I don’t understand the problem with using “method names” e.g. Less() in 
generic code - yes it is a little more verbose - but it avoids the traditional 
problems with operator overloading leading to obtuse code.

> On Oct 18, 2018, at 2:28 PM, Burak Serdar  wrote:
> 
> On Thu, Oct 18, 2018 at 1:22 PM robert engels  wrote:
>> 
>> Can you explain this a bit more, I must be missing something. Using the 
>> example:
>> 
>> func F(a,b type T like(int,X)) {
>>  if a>...
>>  }
>> }
>> 
>> How do you pass a struct to F because < isn’t valid on structs ???
> 
> You missed the part that said "provided X is a type that supports <".
> This was a hypothetical case where we could define < for X.
> 
> 
>> 
>> Which is why I proposed that < maps to Less() and then the primitives 
>> simplicity implement these various methods, and user defined structs MIGHT.
>> 
>> That way you write the code using Less(), and it works with primitives as 
>> well.
>> 
>> 
>> 
>> 
>>> On Oct 18, 2018, at 2:13 PM, bjorn.de.me...@gmail.com wrote:
>>> 
>>> I don't think this is fear, but rather KISS. The reason many people dislike 
>>> contracts from the official proposal is that they are complex and don't 
>>> have a very Go-like syntax.
>>> 
>>> I like this like syntax because I feel it is more Go-like, but also because 
>>> it solves the operator problem rather elegantly and would allow us to unify 
>>> the strings and bytes packages into one generic package.
>>> 
>>> --
>>> 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.
>>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 1:22 PM robert engels  wrote:
>
> Can you explain this a bit more, I must be missing something. Using the 
> example:
>
> func F(a,b type T like(int,X)) {
>   if a ...
>   }
> }
>
> How do you pass a struct to F because < isn’t valid on structs ???

You missed the part that said "provided X is a type that supports <".
This was a hypothetical case where we could define < for X.


>
> Which is why I proposed that < maps to Less() and then the primitives 
> simplicity implement these various methods, and user defined structs MIGHT.
>
> That way you write the code using Less(), and it works with primitives as 
> well.
>
>
>
>
> > On Oct 18, 2018, at 2:13 PM, bjorn.de.me...@gmail.com wrote:
> >
> > I don't think this is fear, but rather KISS. The reason many people dislike 
> > contracts from the official proposal is that they are complex and don't 
> > have a very Go-like syntax.
> >
> > I like this like syntax because I feel it is more Go-like, but also because 
> > it solves the operator problem rather elegantly and would allow us to unify 
> > the strings and bytes packages into one generic package.
> >
> > --
> > 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.
> > 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

Can you explain this a bit more, I must be missing something. Using the example:

func F(a,b type T like(int,X)) {
  if a On Oct 18, 2018, at 2:13 PM, bjorn.de.me...@gmail.com wrote:
> 
> I don't think this is fear, but rather KISS. The reason many people dislike 
> contracts from the official proposal is that they are complex and don't have 
> a very Go-like syntax. 
> 
> I like this like syntax because I feel it is more Go-like, but also because 
> it solves the operator problem rather elegantly and would allow us to unify 
> the strings and bytes packages into one generic package.
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Regarding contracts

2018-10-18 Thread Beoran

Let's get serious about this. I started a GitHub repository to work on this 
proposal. https://github.com/beoran/go-like-generics-proposal/ 
You are all cordially invited to help out fleshing out this proposal.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

2018-10-18 Thread bjorn . de . meyer

I don't think this is fear, but rather KISS. The reason many people dislike 
contracts from the official proposal is that they are complex and don't have a 
very Go-like syntax. 

I like this like syntax because I feel it is more Go-like, but also because it 
solves the operator problem rather elegantly and would allow us to unify the 
strings and bytes packages into one generic package.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 12:28 PM Ian Denhardt  wrote:
>
> Quoting Andy Balholm (2018-10-18 14:00:52)
>
> > That would also be a weakness of most of the other proposals,
> > including my own to add operators to interfaces. Contracts are more
> > powerful, at the expense of extra complexity.
>
> Fwiw, my own proposal for "just using interfaces" covered the graph use
> case. The code doesn't look far off from what Burak sketched in a
> sibling comment, but does have some key differences that I think are
> important to bridge the gap:
>
> 
> https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters
>
> I think adding operators to that proposal actually covers every use case
> covered by the draft design. I left them out originally because of a
> snafu with the == operator, but ESR has offered a way around that.
>
> ---
>
> I feel like Burak's proposal is falling into the same trap as many others:
> there is a common feeling that operator overloading is a Pandora's box, so
> folks are trying to work around it by solving the problem without providing
> operator overloading. But *the problem itself* is not being able to abstract
> over operators, so this approach is doomed to failure. You just result in a
> clumsy design that can't decide if it's trying to allow operators to be
> abstracted over or not, since the whole point is to allow this, but the
> particulars of the design are motivated by a fear of actually doing so.


tbh, I am not trying to avoid operator overloading, I am trying to
avoid the contracts. With operator overloading, you can write:

func F(a,b type T like(int,X)) {
   if a
> I there is a fundamental conflict here. You can express the same concepts
> as with operator overloading if you're willing to wrap the basic types and use
> methods like .Less() in generic code. But I think fundamentally folks have to
> make choice: do we want to be able to write `<` for user defined types, or do
> we want to be able to look at the `<` operator and know for certain that it's
> not calling a method? You can't have both.
>
> -Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Ian Denhardt

Quoting Andy Balholm (2018-10-18 14:00:52)

> That would also be a weakness of most of the other proposals,
> including my own to add operators to interfaces. Contracts are more
> powerful, at the expense of extra complexity.

Fwiw, my own proposal for "just using interfaces" covered the graph use
case. The code doesn't look far off from what Burak sketched in a
sibling comment, but does have some key differences that I think are
important to bridge the gap:

https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters

I think adding operators to that proposal actually covers every use case
covered by the draft design. I left them out originally because of a
snafu with the == operator, but ESR has offered a way around that.

---

I feel like Burak's proposal is falling into the same trap as many others:
there is a common feeling that operator overloading is a Pandora's box, so
folks are trying to work around it by solving the problem without providing
operator overloading. But *the problem itself* is not being able to abstract
over operators, so this approach is doomed to failure. You just result in a
clumsy design that can't decide if it's trying to allow operators to be
abstracted over or not, since the whole point is to allow this, but the
particulars of the design are motivated by a fear of actually doing so.

I there is a fundamental conflict here. You can express the same concepts
as with operator overloading if you're willing to wrap the basic types and use
methods like .Less() in generic code. But I think fundamentally folks have to
make choice: do we want to be able to write `<` for user defined types, or do
we want to be able to look at the `<` operator and know for certain that it's
not calling a method? You can't have both.

-Ian

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Andy Balholm

That would also be a weakness of most of the other proposals, including my own 
to add operators to interfaces. Contracts are more powerful, at the expense of 
extra complexity.

Andy

> On Oct 18, 2018, at 10:34 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar  wrote:
>> 
>> Instead of specifying the minimal set of operations a type should
>> satisfy, why not describe what the type should look like:
>> 
>> func f(in like T)
> 
> I don't see how this approach can handle multiple types that need to
> work together in some known way, like the Graph/Node/Edge case in the
> design draft.
> 
> Ian
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor  wrote:
>
> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar  wrote:
> >
> > Instead of specifying the minimal set of operations a type should
> > satisfy, why not describe what the type should look like:
> >
> > func f(in like T)
>
> I don't see how this approach can handle multiple types that need to
> work together in some known way, like the Graph/Node/Edge case in the
> design draft.


Still discussing the details, but the graph case in the design draft
can look like this:

type Node like interface {
   Edges() []Edge
}

type Edge like interface {
   Nodes() (Node,Node)
}

type Graph like struct {
   Nodes []*Node
}

func New(nodes []*Node) *Graph {
  return &Graph{Nodes:nodes}
}


The instantiation:

type MyNode struct {...}

func (m MyNode) Edges() []MyEdge {...}

type MyEdge  struct { ...}

func (e MyEdge) Nodes() (*MyNode,*MyNode) {...}

type MyGraph graph.Graph {
  Nodes []*MyNodes
}

x:=graph.New(MyGraph)(myNodes)




>
> Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar  wrote:
>
> Instead of specifying the minimal set of operations a type should
> satisfy, why not describe what the type should look like:
>
> func f(in like T)

I don't see how this approach can handle multiple types that need to
work together in some known way, like the Graph/Node/Edge case in the
design draft.

Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 10:13 AM robert engels  wrote:
>
> I guess you could do it that way, but still, then you need to document every 
> private field as if it were public, leading to very brittle code… imagine the 
> compiler error - struct X does not have field xyz… ? Then I need to go to the 
> source of Y and look at how xyz is documented (hopefully), and then hope the 
> implementation never changes… That’s a lot of hoping.

Maybe we're thinking this all wrong. So far we've been talking about
template functions, but not template types.


Let's write the linked list type contract:

package linkedlist

type LinkedList like struct {
  head *like Node
}

type Node like struct {
  next *like Node
}

func (l *LinkedList) Add(in *Node) {
  ...
}


Now let's use the linked list:

type TheLinkedList linkedlist.LinkedList {
  head *TheNode
}

type TheNode linkedlist.Node {
  next *TheNode
  more stuff
}

var myLinkedList TheLinkedList


myLinkedList.Add() works now.

I do not like the "type name templatename" syntax, something else is
needed there.

>
> > On Oct 18, 2018, at 11:08 AM, Burak Serdar  wrote:
> >
> > On Thu, Oct 18, 2018 at 10:03 AM robert engels  
> > wrote:
> >>
> >> Right, that is a big limitation - that means that internal details must be 
> >> made public, or everything in the same package - which is even worse, 
> >> because then you have other private details accessible. Breaks 
> >> encapsulation.
> >
> > That is not correct. This does not require that everything should be
> > in the same package. It requires that the private fields must be
> > accessible where the template is instantiated.
> >
> > If the Add function is declared in package A and used in package B,
> > then Add() would have access to all private fields of package B,
> > because that's where it is instantiated.
> >
> >>
> >> Field access just seems unworkable to me. To much to understand (and 
> >> document) rather than just using interfaces which already need to be 
> >> understood and documented.
> >>
> >> Only allow interfaces as types and I’m fine. The primitives just need 
> >> pseudo interfaces defined for their operations and all is good.
> >>
> >> granted, you would never write a LinkedList like that with embedded 
> >> pointers in the elements - not if you want safe code - but it was just 
> >> used an example of the abuse that will occur.
> >>
> >>
> >> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
> >>
> >> On Thu, Oct 18, 2018 at 9:37 AM robert engels  
> >> wrote:
> >>
> >>
> >> That is true, it would be done that way, so not an issue. Sorry for the 
> >> tangent.
> >>
> >> I still don’t understand when ‘like T’ when T is a concrete type. It seems 
> >> daunting, unless you use the containment as outlined previously - but a X 
> >> containing T, is far different than X being a T, and I am not sure the 
> >> semantics of the function will hold.
> >>
> >> Imagine a
> >>
> >> type Node struct {
> >>  link *Node
> >> }
> >>
> >> then you have a linked list
> >>
> >> type LinkedList struct {
> >>   head *node
> >> }
> >>
> >> with
> >>
> >> func (LinkedList *) Add(n like Node){ blah..}
> >>
> >> passing a
> >>
> >> struct MyNode {
> >>  Node
> >>  value int
> >> }
> >>
> >> will not work, because the reference passed to Add() points to inner 
> >> instance.
> >>
> >>
> >> In this example, neither LinkedList nor Node are templates, but Add is
> >> a template. Let's try to write the Add function.
> >>
> >> func (l *LinkedList) Add(n type *T like(Node)) {
> >> if l.head==nil {
> >>   l.head=n
> >>   n.link=nil
> >>   return
> >> }
> >> tail:=l.head
> >> for tail.link!=nil {
> >>tail=tail.link
> >> }
> >> n.link=nil
> >> tail.link=n
> >> }
> >>
> >> This should compile for:
> >>
> >> l.Add(&MyNode{value:1})
> >>
> >> if private values of MyNode is accessible where it is used. That means
> >> the following won't work:
> >>
> >> package A
> >>
> >> struct MyNode {private fields}
> >>
> >> package B
> >>
> >> l.Add(&A.MyNode{})
> >>
> >> However, if private fields of MyNode is accessible where Add() is
> >> instantiated, Add should compile without any errors.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> you would need to create:
> >>
> >> struct MyNode {
> >>   Link *Node
> >>   value int
> >> }
> >>
> >> and make link exported - meaning you need to understand the internal 
> >> details of LinkedList in order to use it.
> >>
> >> At least I think so… :)
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
> >>
> >> On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  
> >> wrote:
> >>
> >>
> >>
> >>
> >> On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
> >>
> >> If X is a struct type, any type implementing all the methods of X and
> >> containing all the fields of X can be substituted
> >>
> >>
> >> The above is the problem. This almost certainly requires dynamic access to 
> >> fields, essentially making all method and field access dynamic, and I 
> >> don’t think the Go performance hounds

[go-nuts] do you use binary-only packages?

2018-10-18 Thread Russ Cox

The go command supports "binary-only packages", in which
the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg
but the corresponding source code is only a stub with relevant
imports (for linking), a special comment marking it as a binary-only
package, and perhaps documentation for exported API.

While the go command will use these packages if they exist in
GOROOT or GOPATH, 'go get' will not download them: 'go get'
is intentionally only about source code distribution.

Furthermore, binary-only packages only work when the build is
using the exact versions of whatever imported packages are
needed by the binary-only package. If there were any important
differences in a dependency between compilation and linking,
the binary-only portion might have stale information about details
of the imported package, such as type sizes, struct field offsets,
inlined function bodies, escape analysis decisions, and so on,
leading to silent memory corruption at runtime.

Binary-only packages also only work when the build is using the
exact version of the Go toolchain that was used for compilation.
This is at least enforced at link time, with the effect that if your
binary-only package only imports the standard library and you don't
use any special compilation flags, then the toolchain version check
suffices to avoid the silent memory corruption problem described in
the previous package. But if your package imports any non-standard
package for which that the eventual user might try to combine with
a different version, you're in trouble again.

Compiled Go programs also contain much richer amounts of runtime
information than compiled C programs, so that for example all the
details of type declarations, including struct definitions, are in the
compiled code, along with file names and line numbers for the compiled
code, and increasingly good debug information that was impossible to
turn off until very recently. Overall, a binary-only package obscures very
little.

In short, binary-only packages:

- have never been supported by 'go get',
so you've had to go out of your way to use them,
- aren't even guaranteed to work when you do use them,
possibly leading to silent memory corruption, and
- still expose quite a lot more than most people would expect
about the original source code.

For these reasons, we're looking at removing binary-only package
support entirely.

If you use binary-only packages and think it's important to keep that
support around, please let us know either on this thread or at
golang.org/issue/28152.

Thanks.
Russ

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Andy Balholm

I don’t think that generic functions should have access to private fields of 
their type parameters, regardless of what package they are in. 

Andy


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

I guess you could do it that way, but still, then you need to document every 
private field as if it were public, leading to very brittle code… imagine the 
compiler error - struct X does not have field xyz… ? Then I need to go to the 
source of Y and look at how xyz is documented (hopefully), and then hope the 
implementation never changes… That’s a lot of hoping.

> On Oct 18, 2018, at 11:08 AM, Burak Serdar  wrote:
> 
> On Thu, Oct 18, 2018 at 10:03 AM robert engels  wrote:
>> 
>> Right, that is a big limitation - that means that internal details must be 
>> made public, or everything in the same package - which is even worse, 
>> because then you have other private details accessible. Breaks encapsulation.
> 
> That is not correct. This does not require that everything should be
> in the same package. It requires that the private fields must be
> accessible where the template is instantiated.
> 
> If the Add function is declared in package A and used in package B,
> then Add() would have access to all private fields of package B,
> because that's where it is instantiated.
> 
>> 
>> Field access just seems unworkable to me. To much to understand (and 
>> document) rather than just using interfaces which already need to be 
>> understood and documented.
>> 
>> Only allow interfaces as types and I’m fine. The primitives just need pseudo 
>> interfaces defined for their operations and all is good.
>> 
>> granted, you would never write a LinkedList like that with embedded pointers 
>> in the elements - not if you want safe code - but it was just used an 
>> example of the abuse that will occur.
>> 
>> 
>> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
>> 
>> On Thu, Oct 18, 2018 at 9:37 AM robert engels  wrote:
>> 
>> 
>> That is true, it would be done that way, so not an issue. Sorry for the 
>> tangent.
>> 
>> I still don’t understand when ‘like T’ when T is a concrete type. It seems 
>> daunting, unless you use the containment as outlined previously - but a X 
>> containing T, is far different than X being a T, and I am not sure the 
>> semantics of the function will hold.
>> 
>> Imagine a
>> 
>> type Node struct {
>>  link *Node
>> }
>> 
>> then you have a linked list
>> 
>> type LinkedList struct {
>>   head *node
>> }
>> 
>> with
>> 
>> func (LinkedList *) Add(n like Node){ blah..}
>> 
>> passing a
>> 
>> struct MyNode {
>>  Node
>>  value int
>> }
>> 
>> will not work, because the reference passed to Add() points to inner 
>> instance.
>> 
>> 
>> In this example, neither LinkedList nor Node are templates, but Add is
>> a template. Let's try to write the Add function.
>> 
>> func (l *LinkedList) Add(n type *T like(Node)) {
>> if l.head==nil {
>>   l.head=n
>>   n.link=nil
>>   return
>> }
>> tail:=l.head
>> for tail.link!=nil {
>>tail=tail.link
>> }
>> n.link=nil
>> tail.link=n
>> }
>> 
>> This should compile for:
>> 
>> l.Add(&MyNode{value:1})
>> 
>> if private values of MyNode is accessible where it is used. That means
>> the following won't work:
>> 
>> package A
>> 
>> struct MyNode {private fields}
>> 
>> package B
>> 
>> l.Add(&A.MyNode{})
>> 
>> However, if private fields of MyNode is accessible where Add() is
>> instantiated, Add should compile without any errors.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> you would need to create:
>> 
>> struct MyNode {
>>   Link *Node
>>   value int
>> }
>> 
>> and make link exported - meaning you need to understand the internal details 
>> of LinkedList in order to use it.
>> 
>> At least I think so… :)
>> 
>> 
>> 
>> 
>> 
>> 
>> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
>> 
>> On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  wrote:
>> 
>> 
>> 
>> 
>> On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
>> 
>> If X is a struct type, any type implementing all the methods of X and
>> containing all the fields of X can be substituted
>> 
>> 
>> The above is the problem. This almost certainly requires dynamic access to 
>> fields, essentially making all method and field access dynamic, and I don’t 
>> think the Go performance hounds will go for it. I am
>> 
>> 
>> I don't understand this concern either.
>> 
>> func F(in like T)
>> 
>> is a template. When the compiler instantiates F with a concrete type
>> T, a new copy of F is compiled using that type. There is no dynamic
>> access involved there, everything is statically resolved.
>> 
>> not even certain it can be done without runtime reflection.
>> 
>> 
>> But still a developer having to create a Bar with all of the exported 
>> methods and fields of Foo seems daunting.
>> 
>> 
>> --
>> 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.
>> 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 unsubscrib

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 10:03 AM robert engels  wrote:
>
> Right, that is a big limitation - that means that internal details must be 
> made public, or everything in the same package - which is even worse, because 
> then you have other private details accessible. Breaks encapsulation.

That is not correct. This does not require that everything should be
in the same package. It requires that the private fields must be
accessible where the template is instantiated.

If the Add function is declared in package A and used in package B,
then Add() would have access to all private fields of package B,
because that's where it is instantiated.

>
> Field access just seems unworkable to me. To much to understand (and 
> document) rather than just using interfaces which already need to be 
> understood and documented.
>
> Only allow interfaces as types and I’m fine. The primitives just need pseudo 
> interfaces defined for their operations and all is good.
>
> granted, you would never write a LinkedList like that with embedded pointers 
> in the elements - not if you want safe code - but it was just used an example 
> of the abuse that will occur.
>
>
> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
>
> On Thu, Oct 18, 2018 at 9:37 AM robert engels  wrote:
>
>
> That is true, it would be done that way, so not an issue. Sorry for the 
> tangent.
>
> I still don’t understand when ‘like T’ when T is a concrete type. It seems 
> daunting, unless you use the containment as outlined previously - but a X 
> containing T, is far different than X being a T, and I am not sure the 
> semantics of the function will hold.
>
> Imagine a
>
> type Node struct {
>   link *Node
> }
>
> then you have a linked list
>
> type LinkedList struct {
>head *node
> }
>
> with
>
> func (LinkedList *) Add(n like Node){ blah..}
>
> passing a
>
> struct MyNode {
>   Node
>   value int
> }
>
> will not work, because the reference passed to Add() points to inner instance.
>
>
> In this example, neither LinkedList nor Node are templates, but Add is
> a template. Let's try to write the Add function.
>
> func (l *LinkedList) Add(n type *T like(Node)) {
>  if l.head==nil {
>l.head=n
>n.link=nil
>return
>  }
>  tail:=l.head
>  for tail.link!=nil {
> tail=tail.link
>  }
>  n.link=nil
>  tail.link=n
> }
>
> This should compile for:
>
> l.Add(&MyNode{value:1})
>
> if private values of MyNode is accessible where it is used. That means
> the following won't work:
>
> package A
>
> struct MyNode {private fields}
>
> package B
>
> l.Add(&A.MyNode{})
>
> However, if private fields of MyNode is accessible where Add() is
> instantiated, Add should compile without any errors.
>
>
>
>
>
>
>
> you would need to create:
>
> struct MyNode {
>Link *Node
>value int
> }
>
> and make link exported - meaning you need to understand the internal details 
> of LinkedList in order to use it.
>
> At least I think so… :)
>
>
>
>
>
>
> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
>
> On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  wrote:
>
>
>
>
> On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
>
> If X is a struct type, any type implementing all the methods of X and
>  containing all the fields of X can be substituted
>
>
> The above is the problem. This almost certainly requires dynamic access to 
> fields, essentially making all method and field access dynamic, and I don’t 
> think the Go performance hounds will go for it. I am
>
>
> I don't understand this concern either.
>
> func F(in like T)
>
> is a template. When the compiler instantiates F with a concrete type
> T, a new copy of F is compiled using that type. There is no dynamic
> access involved there, everything is statically resolved.
>
> not even certain it can be done without runtime reflection.
>
>
> But still a developer having to create a Bar with all of the exported methods 
> and fields of Foo seems daunting.
>
>
> --
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

Right, that is a big limitation - that means that internal details must be made 
public, or everything in the same package - which is even worse, because then 
you have other private details accessible. Breaks encapsulation.

Field access just seems unworkable to me. To much to understand (and document) 
rather than just using interfaces which already need to be understood and 
documented.

Only allow interfaces as types and I’m fine. The primitives just need pseudo 
interfaces defined for their operations and all is good.

granted, you would never write a LinkedList like that with embedded pointers in 
the elements - not if you want safe code - but it was just used an example of 
the abuse that will occur.


> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
> 
> On Thu, Oct 18, 2018 at 9:37 AM robert engels  > wrote:
>> 
>> That is true, it would be done that way, so not an issue. Sorry for the 
>> tangent.
>> 
>> I still don’t understand when ‘like T’ when T is a concrete type. It seems 
>> daunting, unless you use the containment as outlined previously - but a X 
>> containing T, is far different than X being a T, and I am not sure the 
>> semantics of the function will hold.
>> 
>> Imagine a
>> 
>> type Node struct {
>>   link *Node
>> }
>> 
>> then you have a linked list
>> 
>> type LinkedList struct {
>>head *node
>> }
>> 
>> with
>> 
>> func (LinkedList *) Add(n like Node){ blah..}
>> 
>> passing a
>> 
>> struct MyNode {
>>   Node
>>   value int
>> }
>> 
>> will not work, because the reference passed to Add() points to inner 
>> instance.
> 
> In this example, neither LinkedList nor Node are templates, but Add is
> a template. Let's try to write the Add function.
> 
> func (l *LinkedList) Add(n type *T like(Node)) {
>  if l.head==nil {
>l.head=n
>n.link =nil
>return
>  }
>  tail:=l.head
>  for tail.link !=nil {
> tail=tail.link 
>  }
>  n.link =nil
>  tail.link =n
> }
> 
> This should compile for:
> 
> l.Add(&MyNode{value:1})
> 
> if private values of MyNode is accessible where it is used. That means
> the following won't work:
> 
> package A
> 
> struct MyNode {private fields}
> 
> package B
> 
> l.Add(&A.MyNode{})
> 
> However, if private fields of MyNode is accessible where Add() is
> instantiated, Add should compile without any errors.
> 
> 
> 
> 
> 
> 
>> 
>> you would need to create:
>> 
>> struct MyNode {
>>Link *Node
>>value int
>> }
>> 
>> and make link exported - meaning you need to understand the internal details 
>> of LinkedList in order to use it.
>> 
>> At least I think so… :)
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
>>> 
>>> On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  wrote:
 
 
 
> On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
> 
> If X is a struct type, any type implementing all the methods of X and
>  containing all the fields of X can be substituted
 
 The above is the problem. This almost certainly requires dynamic access to 
 fields, essentially making all method and field access dynamic, and I 
 don’t think the Go performance hounds will go for it. I am
>>> 
>>> I don't understand this concern either.
>>> 
>>> func F(in like T)
>>> 
>>> is a template. When the compiler instantiates F with a concrete type
>>> T, a new copy of F is compiled using that type. There is no dynamic
>>> access involved there, everything is statically resolved.
>>> 
>>> not even certain it can be done without runtime reflection.
 
 But still a developer having to create a Bar with all of the exported 
 methods and fields of Foo seems daunting.
>>> 
>>> --
>>> 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.
>>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 9:37 AM robert engels  wrote:
>
> That is true, it would be done that way, so not an issue. Sorry for the 
> tangent.
>
> I still don’t understand when ‘like T’ when T is a concrete type. It seems 
> daunting, unless you use the containment as outlined previously - but a X 
> containing T, is far different than X being a T, and I am not sure the 
> semantics of the function will hold.
>
> Imagine a
>
> type Node struct {
>link *Node
> }
>
> then you have a linked list
>
> type LinkedList struct {
> head *node
> }
>
> with
>
> func (LinkedList *) Add(n like Node){ blah..}
>
> passing a
>
> struct MyNode {
>Node
>value int
> }
>
> will not work, because the reference passed to Add() points to inner instance.

In this example, neither LinkedList nor Node are templates, but Add is
a template. Let's try to write the Add function.

func (l *LinkedList) Add(n type *T like(Node)) {
  if l.head==nil {
l.head=n
n.link=nil
return
  }
  tail:=l.head
  for tail.link!=nil {
 tail=tail.link
  }
  n.link=nil
  tail.link=n
}

This should compile for:

l.Add(&MyNode{value:1})

if private values of MyNode is accessible where it is used. That means
the following won't work:

package A

struct MyNode {private fields}

package B

l.Add(&A.MyNode{})

However, if private fields of MyNode is accessible where Add() is
instantiated, Add should compile without any errors.






>
> you would need to create:
>
> struct MyNode {
> Link *Node
> value int
> }
>
> and make link exported - meaning you need to understand the internal details 
> of LinkedList in order to use it.
>
> At least I think so… :)
>
>
>
>
>
>
> > On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
> >
> > On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  wrote:
> >>
> >>
> >>
> >>> On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
> >>>
> >>> If X is a struct type, any type implementing all the methods of X and
> >>>   containing all the fields of X can be substituted
> >>
> >> The above is the problem. This almost certainly requires dynamic access to 
> >> fields, essentially making all method and field access dynamic, and I 
> >> don’t think the Go performance hounds will go for it. I am
> >
> > I don't understand this concern either.
> >
> > func F(in like T)
> >
> > is a template. When the compiler instantiates F with a concrete type
> > T, a new copy of F is compiled using that type. There is no dynamic
> > access involved there, everything is statically resolved.
> >
> > not even certain it can be done without runtime reflection.
> >>
> >> But still a developer having to create a Bar with all of the exported 
> >> methods and fields of Foo seems daunting.
> >
> > --
> > 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.
> > 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

That is true, it would be done that way, so not an issue. Sorry for the tangent.

I still don’t understand when ‘like T’ when T is a concrete type. It seems 
daunting, unless you use the containment as outlined previously - but a X 
containing T, is far different than X being a T, and I am not sure the 
semantics of the function will hold.

Imagine a

type Node struct {
   link *Node
}

then you have a linked list

type LinkedList struct {
head *node
}

with

func (LinkedList *) Add(n like Node){ blah..}

passing a 

struct MyNode {
   Node
   value int
}

will not work, because the reference passed to Add() points to inner instance.

you would need to create:

struct MyNode {
Link *Node
value int
}

and make link exported - meaning you need to understand the internal details of 
LinkedList in order to use it.

At least I think so… :)






> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
> 
> On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  wrote:
>> 
>> 
>> 
>>> On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
>>> 
>>> If X is a struct type, any type implementing all the methods of X and
>>>   containing all the fields of X can be substituted
>> 
>> The above is the problem. This almost certainly requires dynamic access to 
>> fields, essentially making all method and field access dynamic, and I don’t 
>> think the Go performance hounds will go for it. I am
> 
> I don't understand this concern either.
> 
> func F(in like T)
> 
> is a template. When the compiler instantiates F with a concrete type
> T, a new copy of F is compiled using that type. There is no dynamic
> access involved there, everything is statically resolved.
> 
> not even certain it can be done without runtime reflection.
>> 
>> But still a developer having to create a Bar with all of the exported 
>> methods and fields of Foo seems daunting.
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Does client.go#transport() reuse s global DefaultTransport when http.Client's Transport is nil?

2018-10-18 Thread Peter Waller

On Wed, 17 Oct 2018 at 17:30, Kyle Butz  wrote:

> It looks like transport() is returning a RoundTripper by value. Does that
> mean that "return DefaultTransport" returns a new copy of DefaultTransport,
> or just a copy of a pointer to the global DefaultTransport defined in
> transport.go?
>

You might find this interesting reading to help build up a mental model:
https://research.swtch.com/interfaces

Another thing to mention, you don't often see pointers-to-interfaces, most
interfaces are passed around by-value. Remember that "an interface value is
internally a tuple of (type, pointer-to-data)", so copying an interface
really copies a pointer around.

Things get a bit more mind bending when you store a value in an interface.
There is still a pointer-to-data in there, but now whenever you access the
value you get a copy of the data out. This is why you can't then call
methods-with-pointer-receivers when you put a value into an interface.

At least, as I understand it :)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Template function arguments from JS

2018-10-18 Thread howardcshaw

I have not done much with golang on the web, so take this with a grain of 
salt.

You are right in judging why it does not work - by the time the Javascript 
runs, the template generation is long over with.

That said, I think you have two basic options:

Option 1: Front-load the data into Javascript

That is, the template needs to write ALL the data necessary for the 
sub-region into Javascript (i.e. have the Template produce a bit of JSON 
assigned to a variable in the script region), then have more Javascript 
that uses that data to render the sub-region on the fly on the basis of the 
selection.

Option 2: Use AJAX to pull a smaller template from your Go server, passing 
in the parameter gathered from Javascript, and replacing the sub-region in 
the DOM. So basically, you'd have more Javascript in the first template, 
and the sub-region would get pulled out into a second template on the Go 
side.

https://stackoverflow.com/questions/41136000/creating-load-more-button-in-golang-with-templates
https://stackoverflow.com/questions/36251743/render-a-partial-template-with-passed-parameters

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  wrote:
>
>
>
> > On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
> >
> > If X is a struct type, any type implementing all the methods of X and
> >containing all the fields of X can be substituted
>
> The above is the problem. This almost certainly requires dynamic access to 
> fields, essentially making all method and field access dynamic, and I don’t 
> think the Go performance hounds will go for it. I am

I don't understand this concern either.

func F(in like T)

is a template. When the compiler instantiates F with a concrete type
T, a new copy of F is compiled using that type. There is no dynamic
access involved there, everything is statically resolved.

not even certain it can be done without runtime reflection.
>
> But still a developer having to create a Bar with all of the exported methods 
> and fields of Foo seems daunting.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 8:53 AM Robert Engels  wrote:
>
>
>
> > On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
> >
> > If X is a struct type, any type implementing all the methods of X and
> >containing all the fields of X can be substituted
>
> The above is the problem. This almost certainly requires dynamic access to 
> fields, essentially making all method and field access dynamic, and I don’t 
> think the Go performance hounds will go for it. I am not even certain it can 
> be done without runtime reflection.
>
> But still a developer having to create a Bar with all of the exported methods 
> and fields of Foo seems daunting.

That is not intended for copy paste. That is intended for the following case:

type S struct {
   blah...
}

func (s S) F() { ... }


func W(in like S) {
}

type K struct {
 S
}


You can call W(K{})

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

> On Oct 18, 2018, at 9:41 AM, Burak Serdar  wrote:
> 
> If X is a struct type, any type implementing all the methods of X and
>containing all the fields of X can be substituted

The above is the problem. This almost certainly requires dynamic access to 
fields, essentially making all method and field access dynamic, and I don’t 
think the Go performance hounds will go for it. I am not even certain it can be 
done without runtime reflection. 

But still a developer having to create a Bar with all of the exported methods 
and fields of Foo seems daunting. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 8:01 AM Robert Engels  wrote:
>
> Try it with a user defined type. The only point of generic is to write a 
> method once. So when I call it with another type it works correctly. So if 
> you write the generic method with a like Foo but I want to call it with a Bar 
> what methods does Bar need to implement ? All of the methods of Foo - hard to 
> determine as a developer - easily anyway.


I don't think the problem you described exists. Let's take this one
step further:

(I'll continue using the "like" keyword for now until something better
comes up. Also, Andy is right, the syntax has problems. I'll use a
syntax similar to the one given in the official proposal)

A type template is declared like this:

type T like (X,Y,...)

This means that any one of X, Y, ... can be substituted in place of
T. In effect, it is the intersection of the operations defined on X,
Y, ...

  - If X is a primitive type such as int, any type derived from int
can be substituted.
  - If X is an interface type, any type implementing X can be substituted
  - If X is a struct type, any type implementing all the methods of X and
containing all the fields of X can be substituted

I think the above specification solves the problem Robert mentioned:
for a template using a user defined type Foo, you can substitute any
type that implements Foo.

  - If X is an array type, map type, or channel type, then any
array/map/channel type derived from X can be substituted.
That is:

  type ArrType []int

can be substituted for

  type T like []int

but not for:

  type T like []int64


Based on the above, the following should also be meaningful within templates:

   map: this would be a map template whose values are
   described by T.
   []like int : An array of int-like values


Function template is declared like this:

  func F(a, b type T like (X, Y)) T

or if T is already defined as a type template:

  func F(a,b T) T

An interface template can be defined like this:

type I interface_template {
  F(a type T like(int)) T
}

A function with an interface template in its signature becomes a template:

func F(in I)


Need to work on some real examples to see how this develops...

>
> > On Oct 18, 2018, at 8:09 AM, Burak Serdar  wrote:
> >
> >> On Thu, Oct 18, 2018 at 6:35 AM Robert Engels  
> >> wrote:
> >>
> >> I meant to say contract not interface. Also as a user of said generic 
> >> routine how do I know all of the available method on a type I would need 
> >> to implement as I don’t know which ones the method may be using...
> >>
> >> Interfaces solve the latter as I need to implement all of them in order to 
> >> be an interface.
> >>
> >> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
> >>
> >> I think the problem with the proposal is that it is going to be very hard 
> >> for the compiler to know all of the operations a type can perform since 
> >> for concrete types the methods can be spread across multiple files. With 
> >> an interface it is only declared in a single location.
> >
> >
> > I don't understand why that would be a problem. For a method
> > declaration of the form:
> >
> > func f(type T like (int64,float64)(a,b))
> >
> > the compiler compiles f twice: once as func f(a,b int64) and once as
> > func f(a,b float64). In general, for a function f with multiple
> > parameterized types containing multiple "like" types, f is compiled
> > for all combinations of those "like" types.
> >
> > So the compiler doesn't need to know all the operations a type has.
> >
> >>
> >> On Oct 18, 2018, at 2:20 AM, Beoran  wrote:
> >>
> >> I think the idea we should focus on here is "The type is the contract".
> >> Instead of specifying a contract though operations, just use concrete 
> >> types, including primitive types to specify the desired qualities of the 
> >> generic type.
> >>
> >> Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak:
> >>>
> >>> If you require that a single like type applies to all the labels in the
> >>> parameter declaration, such that func f(a, b T like int, c, d T2 like
> >>> string) means a and be must be like T's instantiating type, and c and d
> >>> must be like T2's unstantiating type, then you get that.
> >>>
> >>> If you only require a single like for any type T, something like func
> >>> f(in T like int) (out T), then you get the type safety on return.
> >>>
> >>> Of course, this takes you back essentially to contracts, but with an
> >>> alternative declaration for the type characteristics.
> >>>
> >>> Maybe it would be possible to use like in contracts in place of the
> >>> example-base approach.
> >>>
>  On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote:
>  I think there are serious issues with your syntax for functions and
>  “templates.” For example, there doesn’t seem to be a way to specify
>  that two parameters to a function need to be the same type, or that
>  the return type will be the same as the parameter. The syntax fr

Re: [go-nuts] Regarding contracts

Try it with a user defined type. The only point of generic is to write a method 
once. So when I call it with another type it works correctly. So if you write 
the generic method with a like Foo but I want to call it with a Bar what 
methods does Bar need to implement ? All of the methods of Foo - hard to 
determine as a developer - easily anyway. 

> On Oct 18, 2018, at 8:09 AM, Burak Serdar  wrote:
> 
>> On Thu, Oct 18, 2018 at 6:35 AM Robert Engels  wrote:
>> 
>> I meant to say contract not interface. Also as a user of said generic 
>> routine how do I know all of the available method on a type I would need to 
>> implement as I don’t know which ones the method may be using...
>> 
>> Interfaces solve the latter as I need to implement all of them in order to 
>> be an interface.
>> 
>> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
>> 
>> I think the problem with the proposal is that it is going to be very hard 
>> for the compiler to know all of the operations a type can perform since for 
>> concrete types the methods can be spread across multiple files. With an 
>> interface it is only declared in a single location.
> 
> 
> I don't understand why that would be a problem. For a method
> declaration of the form:
> 
> func f(type T like (int64,float64)(a,b))
> 
> the compiler compiles f twice: once as func f(a,b int64) and once as
> func f(a,b float64). In general, for a function f with multiple
> parameterized types containing multiple "like" types, f is compiled
> for all combinations of those "like" types.
> 
> So the compiler doesn't need to know all the operations a type has.
> 
>> 
>> On Oct 18, 2018, at 2:20 AM, Beoran  wrote:
>> 
>> I think the idea we should focus on here is "The type is the contract".
>> Instead of specifying a contract though operations, just use concrete types, 
>> including primitive types to specify the desired qualities of the generic 
>> type.
>> 
>> Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak:
>>> 
>>> If you require that a single like type applies to all the labels in the
>>> parameter declaration, such that func f(a, b T like int, c, d T2 like
>>> string) means a and be must be like T's instantiating type, and c and d
>>> must be like T2's unstantiating type, then you get that.
>>> 
>>> If you only require a single like for any type T, something like func
>>> f(in T like int) (out T), then you get the type safety on return.
>>> 
>>> Of course, this takes you back essentially to contracts, but with an
>>> alternative declaration for the type characteristics.
>>> 
>>> Maybe it would be possible to use like in contracts in place of the
>>> example-base approach.
>>> 
 On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote:
 I think there are serious issues with your syntax for functions and
 “templates.” For example, there doesn’t seem to be a way to specify
 that two parameters to a function need to be the same type, or that
 the return type will be the same as the parameter. The syntax from
 the official proposal is superior in that regard.
 
 But replacing contracts with “like” definitely sounds like something
 worth investigating.
 
 Andy
 
>> 
>> --
>> 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.
>> 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.
>> 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.
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

2018-10-18 Thread Matthias Schmidt

Hi Burak,

and thanks pointing to you work. The memory-pinning was rather easy to 
integrate, have a look:

https://github.com/ms140569/loki/commit/ad02ac092e56d4ac96ffaf8b737dac515516abfe

Timing-out the key-agent is something which came to my mind as well - i 
guess i'll do it optionally.

cheers,

Matthias


Am Donnerstag, 18. Oktober 2018 15:32:28 UTC+2 schrieb Burak Serdar:
>
> On Tue, Oct 16, 2018 at 1:55 PM Matthias Schmidt 
> > wrote: 
> > 
> > And here it is: 
> > 
> > https://github.com/ms140569/loki/releases/tag/1.2.0 
>
>
> Thanks for sharing this. I find this interesting because I've been 
> working on a very similar idea for an OIDC token manager CLI, and came 
> up with almost the same scheme regarding how you used the domain 
> sockets and the agent. I used rpc instead of a raw protocol though, 
> and the agent times out after a while in my case. You can take a look 
> at https://github.com/bserdar/took the crypto rpc stuff is under 
> crypta package. 
>
> It does suffer from the same problems mentioned in this thread: if you 
> can scan the memory, the master key is there. I'll add memory locking 
> to mine. 
>
> > 
> > Thanks to your guy's input the key-agent should be now way more secure. 
> > 
> > cheers, 
> > 
> > Matthias 
> > 
> > Am Dienstag, 16. Oktober 2018 20:31:42 UTC+2 schrieb Matthias Schmidt: 
> >> 
> >> Hi Christopher + Eric, 
> >> 
> >> thanks for your feedback. You are right, i really underestimated the 
> risk of such attacks. 
> >> 
> >> I will lock the key-holding memory in the next release. 
> >> 
> >> cheers, 
> >> 
> >> Matthias 
> >> 
> >> 
> >> Am Montag, 15. Oktober 2018 23:13:32 UTC+2 schrieb Christopher Nielsen: 
> >>> 
> >>> On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt 
> >>>  wrote: 
> >>> > 
> >>> > Hi Eric, 
> >>> > 
> >>> > thanks *a lot* for your valuable feedback! I really appreciate it. 
> See comments inline: 
> >>> > 
> >>> > Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR: 
> >>> >> 
> >>> >> Since you're looking for opinions on the security concept, two 
> questions spring immediately to my mind: 
> >>> >> 
> >>> >> 1. Does the daemon keep the sensitive data in locked memory that 
> cannot be paged out? If so, how cross-platform is this? 
> >>> > 
> >>> > 
> >>> > No it doesn't. As of now i consider the root-user a good guy ;-) 
> >>> > He's the only one who could access the pagefiles anyway. 
> >>> > 
> >>> > So is this really an issue? If yes i could use this cross-platform 
> solution to pin the key: 
> >>> > 
> >>> > https://github.com/awnumar/memguard 
> >>> > 
> >>> > 
> >>> >> 
> >>> >> 
> >>> >> 2. How does the client communicate securely with the daemon? Which 
> encryption protocol/handshake is used for this? (If it just uses a socket, 
> what would prevent another process from reading out the master password?) 
> >>> > 
> >>> > 
> >>> > It's in fact a unix domain socket file which is only accessible for 
> the owner of the key. ( Thanks for bringing this up, i forgot to flag the 
> file correctly - it's now fixed). 
> >>> > Relying on the file permissions in unix shouldn't be a problem, 
> right? 
> >>> > 
> >>> > cheers & again - many thanks, 
> >>> > 
> >>> > Matthias 
> >>> 
> >>> You seem to be putting a lot of trust in facilities that are trivially 
> >>> exploitable to a determined attacker. For software like a password 
> >>> manager, assuming the kernel is secure is a poor security model. In 
> >>> addition to the existing attack surface, we live in a world where 
> >>> side-channel attacks are becoming more common, e.g., Spectre and 
> >>> Meltdown, so it isn't safe to assume the kernel or hardware are 
> >>> secure. A password manager needs to have a robust security model that 
> >>> has a minimal trust model if it is to be more than a toy. 
> >>> 
> >>> Just my $0.02 
> >>> 
> >>> -- 
> >>> Christopher Nielsen 
> >>> "They who can give up essential liberty for temporary safety, deserve 
> >>> neither liberty nor safety." --Benjamin Franklin 
> >>> "The tree of liberty must be refreshed from time to time with the 
> >>> blood of patriots & tyrants." --Thomas Jefferson 
> > 
> > -- 
> > 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...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

On Tue, Oct 16, 2018 at 1:55 PM Matthias Schmidt
 wrote:
>
> And here it is:
>
> https://github.com/ms140569/loki/releases/tag/1.2.0


Thanks for sharing this. I find this interesting because I've been
working on a very similar idea for an OIDC token manager CLI, and came
up with almost the same scheme regarding how you used the domain
sockets and the agent. I used rpc instead of a raw protocol though,
and the agent times out after a while in my case. You can take a look
at https://github.com/bserdar/took the crypto rpc stuff is under
crypta package.

It does suffer from the same problems mentioned in this thread: if you
can scan the memory, the master key is there. I'll add memory locking
to mine.

>
> Thanks to your guy's input the key-agent should be now way more secure.
>
> cheers,
>
> Matthias
>
> Am Dienstag, 16. Oktober 2018 20:31:42 UTC+2 schrieb Matthias Schmidt:
>>
>> Hi Christopher + Eric,
>>
>> thanks for your feedback. You are right, i really underestimated the risk of 
>> such attacks.
>>
>> I will lock the key-holding memory in the next release.
>>
>> cheers,
>>
>> Matthias
>>
>>
>> Am Montag, 15. Oktober 2018 23:13:32 UTC+2 schrieb Christopher Nielsen:
>>>
>>> On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt
>>>  wrote:
>>> >
>>> > Hi Eric,
>>> >
>>> > thanks *a lot* for your valuable feedback! I really appreciate it. See 
>>> > comments inline:
>>> >
>>> > Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
>>> >>
>>> >> Since you're looking for opinions on the security concept, two questions 
>>> >> spring immediately to my mind:
>>> >>
>>> >> 1. Does the daemon keep the sensitive data in locked memory that cannot 
>>> >> be paged out? If so, how cross-platform is this?
>>> >
>>> >
>>> > No it doesn't. As of now i consider the root-user a good guy ;-)
>>> > He's the only one who could access the pagefiles anyway.
>>> >
>>> > So is this really an issue? If yes i could use this cross-platform 
>>> > solution to pin the key:
>>> >
>>> > https://github.com/awnumar/memguard
>>> >
>>> >
>>> >>
>>> >>
>>> >> 2. How does the client communicate securely with the daemon? Which 
>>> >> encryption protocol/handshake is used for this? (If it just uses a 
>>> >> socket, what would prevent another process from reading out the master 
>>> >> password?)
>>> >
>>> >
>>> > It's in fact a unix domain socket file which is only accessible for the 
>>> > owner of the key. ( Thanks for bringing this up, i forgot to flag the 
>>> > file correctly - it's now fixed).
>>> > Relying on the file permissions in unix shouldn't be a problem, right?
>>> >
>>> > cheers & again - many thanks,
>>> >
>>> > Matthias
>>>
>>> You seem to be putting a lot of trust in facilities that are trivially
>>> exploitable to a determined attacker. For software like a password
>>> manager, assuming the kernel is secure is a poor security model. In
>>> addition to the existing attack surface, we live in a world where
>>> side-channel attacks are becoming more common, e.g., Spectre and
>>> Meltdown, so it isn't safe to assume the kernel or hardware are
>>> secure. A password manager needs to have a robust security model that
>>> has a minimal trust model if it is to be more than a toy.
>>>
>>> Just my $0.02
>>>
>>> --
>>> Christopher Nielsen
>>> "They who can give up essential liberty for temporary safety, deserve
>>> neither liberty nor safety." --Benjamin Franklin
>>> "The tree of liberty must be refreshed from time to time with the
>>> blood of patriots & tyrants." --Thomas Jefferson
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 6:35 AM Robert Engels  wrote:
>
> I meant to say contract not interface. Also as a user of said generic routine 
> how do I know all of the available method on a type I would need to implement 
> as I don’t know which ones the method may be using...
>
> Interfaces solve the latter as I need to implement all of them in order to be 
> an interface.
>
> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
>
> I think the problem with the proposal is that it is going to be very hard for 
> the compiler to know all of the operations a type can perform since for 
> concrete types the methods can be spread across multiple files. With an 
> interface it is only declared in a single location.


I don't understand why that would be a problem. For a method
declaration of the form:

func f(type T like (int64,float64)(a,b))

the compiler compiles f twice: once as func f(a,b int64) and once as
func f(a,b float64). In general, for a function f with multiple
parameterized types containing multiple "like" types, f is compiled
for all combinations of those "like" types.

So the compiler doesn't need to know all the operations a type has.

>
> On Oct 18, 2018, at 2:20 AM, Beoran  wrote:
>
> I think the idea we should focus on here is "The type is the contract".
> Instead of specifying a contract though operations, just use concrete types, 
> including primitive types to specify the desired qualities of the generic 
> type.
>
> Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak:
>>
>> If you require that a single like type applies to all the labels in the
>> parameter declaration, such that func f(a, b T like int, c, d T2 like
>> string) means a and be must be like T's instantiating type, and c and d
>> must be like T2's unstantiating type, then you get that.
>>
>> If you only require a single like for any type T, something like func
>> f(in T like int) (out T), then you get the type safety on return.
>>
>> Of course, this takes you back essentially to contracts, but with an
>> alternative declaration for the type characteristics.
>>
>> Maybe it would be possible to use like in contracts in place of the
>> example-base approach.
>>
>> On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote:
>> > I think there are serious issues with your syntax for functions and
>> > “templates.” For example, there doesn’t seem to be a way to specify
>> > that two parameters to a function need to be the same type, or that
>> > the return type will be the same as the parameter. The syntax from
>> > the official proposal is superior in that regard.
>> >
>> > But replacing contracts with “like” definitely sounds like something
>> > worth investigating.
>> >
>> > Andy
>> >
>
> --
> 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.
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Beoran

How so? 

When you do 

foo := foo.Foo{}
foo.Bar()

The compiler also has to look up Bar() for the type Foo, nothing special or 
difficult about that. In Go, the places where the compiler has to look are 
quite limited, I think. Furthermore with the currently proposed contracts, 
much the same lookup has to be done anyway.

But if it tuns out a problem then we could limit it to interfaces + complex 
native types only, which will cover operators on those native types also.


Op donderdag 18 oktober 2018 14:22:00 UTC+2 schreef Robert Engels:
>
> I think the problem with the proposal is that it is going to be very hard 
> for the compiler to know all of the operations a type can perform since for 
> concrete types the methods can be spread across multiple files. With an 
> interface it is only declared in a single location. 
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

2018-10-18 Thread 'Axel Wagner' via golang-nuts

On Thu, Oct 18, 2018 at 2:06 PM roger peppe  wrote:

> For generics, that analysis is trivial - there is no need to do any
> control flow analysis to determine the set of possible generic type
> parameters to a type or function (with the exception of recursive generic
> functions, which can be disallowed).
>
> For interfaces, the job is much harder. Guru can do it, but only to a
> limited extent.  And in general it's not possible a) because the number of
> possible types is not bounded (you can create new types with the reflect
> package, or by dynamically loading modules) and b) because you'd need to
> solve the halting problem.
>

I don't understand what you're trying to say. These two cases are not
relevant here, because you can't actually do them with the contracts design
- in fact, at least the reflection one is specifically called out in the
"Dual implementation" section of the overview. I never claimed the analysis
for interfaces is *easier*, I claimed that it's *exactly as hard.*

Or, to put it another way: That "limited extend" you mention is exactly the
extend to which the compiler can do that proof for generics. So doing it to
that extend provides you with the same performance benefit.

Or, if you prefer: The type-checker and/or heuristic for whether to
specialize a function for generics provides a blue-print for how to do the
equivalent analysis for interfaces.

But in the case where your first paragraph applies - i.e. you can
>> statically know the full set of types a generic function or type is
>> instantiated with - the exact same analysis can also provide exactly the
>> same results for interface-based polymorphism.
>>
>
> It really can't.  The analysis needed for parametric types need not look
> at anything other than type parameters. The analysis needed for interfaces
> needs to analyse the code itself. A few examples:
> https://play.golang.org/p/CEzBpsRIVGQ
>

AFAICT none of these map to contracts either.

But I guess we won't agree here. AFAIR it's not the first time we had this
argument. :)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts

I meant to say contract not interface. Also as a user of said generic routine 
how do I know all of the available method on a type I would need to implement 
as I don’t know which ones the method may be using...

Interfaces solve the latter as I need to implement all of them in order to be 
an interface. 

> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
> 
> I think the problem with the proposal is that it is going to be very hard for 
> the compiler to know all of the operations a type can perform since for 
> concrete types the methods can be spread across multiple files. With an 
> interface it is only declared in a single location. 
> 
>> On Oct 18, 2018, at 2:20 AM, Beoran  wrote:
>> 
>> I think the idea we should focus on here is "The type is the contract". 
>> Instead of specifying a contract though operations, just use concrete types, 
>> including primitive types to specify the desired qualities of the generic 
>> type. 
>> 
>> Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak:
>>> 
>>> If you require that a single like type applies to all the labels in the 
>>> parameter declaration, such that func f(a, b T like int, c, d T2 like 
>>> string) means a and be must be like T's instantiating type, and c and d 
>>> must be like T2's unstantiating type, then you get that. 
>>> 
>>> If you only require a single like for any type T, something like func 
>>> f(in T like int) (out T), then you get the type safety on return. 
>>> 
>>> Of course, this takes you back essentially to contracts, but with an 
>>> alternative declaration for the type characteristics. 
>>> 
>>> Maybe it would be possible to use like in contracts in place of the 
>>> example-base approach. 
>>> 
>>> On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote: 
>>> > I think there are serious issues with your syntax for functions and 
>>> > “templates.” For example, there doesn’t seem to be a way to specify 
>>> > that two parameters to a function need to be the same type, or that 
>>> > the return type will be the same as the parameter. The syntax from 
>>> > the official proposal is superior in that regard. 
>>> > 
>>> > But replacing contracts with “like” definitely sounds like something 
>>> > worth investigating. 
>>> > 
>>> > Andy 
>>> > 
>> 
>> -- 
>> 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.
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Regarding contracts