Re: [go-nuts] [generics] Constraint type inference not working

[jake...@gmail.com]

Submitted https://github.com/golang/go/issues/40859

On Tuesday, August 18, 2020 at 12:59:21 AM UTC-4 Ian Lance Taylor wrote:

> On Sun, Aug 16, 2020 at 7:42 AM jake...@gmail.com  
> wrote:
> >
> > When I try the example from the "Constraint type inference" section of 
> the Draft Design: 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>  
> it does not seem to actually work:
> >
> > https://go2goplay.golang.org/p/pfq3QV6gdgf
> >
> > What am I missing?
>
> I'm not sure. Can you open a bug report? Thanks.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0c180e02-ac28-4c20-b42c-50ee51bdd7dbn%40googlegroups.com.

Re: [go-nuts] Re: Why we don't have simple throws error statement

[Yasar Semih Alev]

Another idea, if we use blank identifier for errors then throws statement 
catch these with caller function name.

func printSum(a, b, c string) error { 
 throws func(caller string, err error) {
 fmt.Println("caller:", caller, err)
 return err
 }()

 x, _ := strconv.Atoi(a)
 y, _ := strconv.Atoi(b) 
 z, err := strconv.Atoi(c)
 if err != nil {
 return err
 }

 fmt.Println("result:", x + y + z)

 return nil
}

How is sound?

Semih.
On Sunday, 2 August 2020 at 11:44:43 UTC+3 Denis Cheremisov wrote:

> There are two major issues with Go error handling:
>
>
>1. It is not strict enough, i.e. the compiler cannot ensure error check
>2. It is not consistent enough.
>
> In the first you can easily ignore an error and the compiler will let you 
> go further. In the second, you can both
>
> *if err := doSomething(); err != nil {*
> *}*
>
> and
>
> *v, err := returnSomething()*
> *if err != nil {*
> *}*
>
> *or err* would do this better for sure
>
> *doSomething() or err {*
> *}*
>
> and
>
> *v := returnSomething() or err {*
> *}*
>
> воскресенье, 2 августа 2020 г. в 03:55:59 UTC+3, skinne...@gmail.com: 
>
>> I do not consider error handling an issue but then again I tend to either 
>> use the Doit() err{} or MustDoit(){} panic and then use  DI (dependency 
>> injection implemented by interface) for error-handling so that I can get an 
>> email when we get a new error. So then it would be 
>> MustDoit(errorHandler("ConIo")){} 
>>
>> Actually I suppose it is an issue, I do not do error handling in Go, but 
>> my preprocessor converts it to Go. Go error handling can do anything, the 
>> implementation may not be clear and that may be the real problem. We can 
>> change it by improving the language or by training programmers on 
>> recognizing useful abstractions, may need both.
>>
>>
>> On Saturday, August 1, 2020 at 1:31:54 PM UTC-5 Ian Lance Taylor wrote:
>>
>>> On Sat, Aug 1, 2020 at 10:59 AM  wrote: 
>>> > 
>>> > Has anyone ever tallied the number of different forum threads related 
>>> to changing Go error handling ? 
>>> > The current method is obviously a vexing issue to many Go users, and 
>>> > It seems silly that this issue has never been resolved by the Go team 
>>> beyond maintaining the status quo... despite, IMHO, several good 
>>> alternatives that have been suggested on this very forum. 
>>>
>>> There have been many alternatives suggested, but none of them have 
>>> been clearly better. 
>>>
>>> I recently wrote a brief overview at https://golang.org/issue/40432. 
>>>
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d4db0d43-3935-4d3e-8f93-ab4852fda8d1n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Jan Mercl]

On Tue, Aug 18, 2020 at 4:38 PM Frederik Zipp  wrote:

> The draft syntax for type lists is a comma separated list:
>
> type SignedInteger interface {
> type int, int8, int16, int32, int64
> }
>
> Wouldn't it be more consistent with existing Go syntax regarding types if it 
> was a semicolon separated list in curly braces?

I don't think so. The type list in this case is syntactically just an
identifier list, i.e not a list containing possibly eg. type
literals/anonymous types.

And identifier lists are everywhere else comma separated.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X2bFHTsKz7k1b3dspR_d_B5uPegEnxeEaDY5z5FB5Lfg%40mail.gmail.com.

Re: [go-nuts] [Generics] Constraints package name

[Frederik Zipp]

ma...@acln.ro schrieb am Montag, 27. Juli 2020 um 08:34:04 UTC+2:

> The entire notion of the constraints package feels a little suspicious to 
> me. What if the comparable and ordered constraints were pre-declared in the 
> universe block, and the numeric constraint were named math.Numeric?
>

In this case 'Ordered' might belong in the "sort" package: sort.Ordered, 
and most other constraints in the 'math' package: math.Numeric, 
math.Complex, math.Unsigned. Or maybe 'Complex' belongs in "math/cmplx" as 
cmplx.Number.

But from a dependency hygiene perspective it is probably better to have the 
most common constraints in a dedicated package rather than distribute them 
over existing packages. I suppose we would not want "math" to import "sort" 
in order to implement Min and Max.

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7a189321-ff08-4ca7-a7fd-fe00fc9ce613n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

['Axel Wagner' via golang-nuts]

I think in the overwhelmingly common case (a type-list being a list of
identifiers or short type-constructors like channels or slices), having a
line per item takes up a lot of vertical real-estate for little use. Also,
hopefully, almost never would really use them anyway, with basically all
useful combinations being defined in the constraints package.

On Tue, Aug 18, 2020 at 5:29 PM Frederik Zipp 
wrote:

> Jan Mercl schrieb am Dienstag, 18. August 2020 um 16:45:54 UTC+2:
>
>> I don't think so. The type list in this case is syntactically just an
>> identifier list, i.e not a list containing possibly eg. type
>> literals/anonymous types.
>>
>
> I just looked into the draft design again: If composite types like slices
> and structs are allowed, as discussed in [1] and [2], then it is not just
> an identifier list.
>
> [1] Composite types in constraints
> 
>
> type byteseq interface {
> type string, []byte
> }
>
> [2] Notes on composite types in type lists
> 
>
> type structField interface {
> type struct { a int; x int },
> struct { b int; x float64 },
> struct { c int; x uint64 }
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/48c0d6fb-16ce-4495-b520-d4a28166c122n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEC1VUe71kAixDgybRj%3DZZjc4KJSH5ZQm6L_pQVCs04Hg%40mail.gmail.com.

[go-nuts] [generics] Type list syntax

[Frederik Zipp]

The draft syntax for type lists is a comma separated list:

type SignedInteger interface {
type int, int8, int16, int32, int64
}

Wouldn't it be more consistent with existing Go syntax regarding types if 
it was a semicolon separated list in curly braces?

type SignedInteger interface {
type {int; int8; int16; int32; int64}
}

With automatic semicolon insertion:

type SignedInteger interface {
type {
int
int8
int16
int32
int64
}
}

At least that's how 'struct' and 'interface' separate their items.

If some day, somehow, type lists should emerge from 'interface' as 
non-nilable sum types, the natural syntax would be:

type MySum type {
A
B
}

var mySum type{A; B}

Even if this will never happen, this thought experiment suggests that curly 
braces and semicolons are the more Go-like syntax choice for type lists.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f1c5ef30-833b-4fd7-b6a6-68cef4f7ec9fn%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Jan Mercl schrieb am Dienstag, 18. August 2020 um 16:45:54 UTC+2:

> i.e not a list containing possibly eg. type literals/anonymous types. 
>

Yes, I wanted to interpret a type list conceptually as an anonymous type 
embedded in an interface.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d202511e-cf2d-44da-afc6-feea3b579911n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 17:44:16 
UTC+2:

> I think in the overwhelmingly common case (a type-list being a list of 
> identifiers or short type-constructors like channels or slices), having a 
> line per item takes up a lot of vertical real-estate for little use. 
>

Both options, single line and multi-line, are still available with curly 
braces and semicolons, but in the multi-line case you do not have to manage 
trailing commas, and the first line containing type(s) is not indented 
differently than the following lines.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b2cfd94c-50d0-48df-b371-b018c08b4a23n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Jan Mercl schrieb am Dienstag, 18. August 2020 um 16:45:54 UTC+2:

> I don't think so. The type list in this case is syntactically just an 
> identifier list, i.e not a list containing possibly eg. type  
> literals/anonymous types. 
>

I just looked into the draft design again: If composite types like slices 
and structs are allowed, as discussed in [1] and [2], then it is not just 
an identifier list.

[1] Composite types in constraints 


type byteseq interface {
type string, []byte
}

[2] Notes on composite types in type lists 


type structField interface {
type struct { a int; x int },
struct { b int; x float64 },
struct { c int; x uint64 }
}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/48c0d6fb-16ce-4495-b520-d4a28166c122n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

['Axel Wagner' via golang-nuts]

On Tue, Aug 18, 2020 at 8:29 PM Frederik Zipp 
wrote:

> The more I think about it the less I understand why type list should
> reside inside interfaces. I can only think of two reasons:
>
> 1) Avoid a new keyword for type lists.
>
2) The idea that only interfaces should be able to act as constraints.
>

I would argue it's neither, or both. The point is that we want a way to
express constraints on type-parameters, allowing only certain types. We
already have a way to express "any of a certain subset of types", which are
interfaces, so using them for constraints is natural. They are also likely
the most useful constraints - I would expect most Go users to *only* write
pure-method interfaces and use the `constraints` package to write
adaptor-functions for non-composite types.

Meanwhile, we also want to be able to use operators, so there needs to be a
way to fit that into the design and adding a new capability to interfaces
is one such way.

So, it's not 1, because it's not just about avoiding a new keyword, it's
about avoiding a new *concept*. And it's not 2, because it's not really
about *only* interfaces being usable as constraints, but definitely *also*
(and probably at least primarily) interfaces being usable as constraints.

FWIW, this topic has recently (and a couple of times before that) been
discussed here:
https://groups.google.com/g/golang-nuts/c/fCGL7iD8h2Q/m/hWELAQWcBQAJ

Regarding 2): Why this artificial limitation? Why not allow all types as
> constraints? Even int. It's nonsensical, but it would be like "interface{
> type int }" in the current draft, which is nonsensical, too.
>

No, it is neither the same, nor is it nonsensical. `interface{ type int }`
is any type with *underlying type* `int`, not just `int`. It adds some
expressive power. I'm not sure how important that expressive power is, but
it's more than zero.

Meanwhile, the natural meaning of using a concrete type *is* actually
nonsensical.

The rule would be simple: Any type can act both as normal type and as
> constraint. With the possible exception of `anyof`s, until there is a
> solution to use them as regular types as well.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8711bcf9-6ebe-4014-9034-d0a642078791n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF0A%3DdeyVEJJqtABN_gapEcEbVtpPU6d4QcYKKywSYqkw%40mail.gmail.com.

Re: [go-nuts] [generics] Type list syntax

[Ian Lance Taylor]

On Tue, Aug 18, 2020 at 7:38 AM Frederik Zipp  wrote:
>
> The draft syntax for type lists is a comma separated list:
>
> type SignedInteger interface {
> type int, int8, int16, int32, int64
> }
>
> Wouldn't it be more consistent with existing Go syntax regarding types if it 
> was a semicolon separated list in curly braces?
>
> type SignedInteger interface {
> type {int; int8; int16; int32; int64}
> }

Adding to what others have said, I don't see why this syntax is more
consistent with existing syntax.  Both struct fields and interface
methods, which are separated using semicolons, are an example of
concatenation: the fields and methods are concatenated together, and
all the concatenated elements are present in the final type.  Type
lists as used in constraints are an example of alternation: exactly
one of the types is chosen.  I can't think of any other example of
alternation in Go, so there isn't any syntax to be consistent with.


> If some day, somehow, type lists should emerge from 'interface' as 
> non-nilable sum types, the natural syntax would be:
>
> type MySum type {
> A
> B
> }
>
> var mySum type{A; B}
>
> Even if this will never happen, this thought experiment suggests that curly 
> braces and semicolons are the more Go-like syntax choice for type lists.

If we were to introduce non-nilable sum types, I think it would be
quite unlikely that the syntax would be "type MySum type { ... }".
That seems fairly obscure.  Admittedly, that might be a reason to use
a different syntax in type constraints.  But it's not a convincing
argument for using "type { A; B }" in a type constraint.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUg2oHhLy9YL1xxC0PDZyw9awBwhe_Hzb2_F%2BQj2gZ6WQ%40mail.gmail.com.

Re: [go-nuts] [generics] Type list syntax

[Ian Lance Taylor]

On Tue, Aug 18, 2020 at 1:48 PM Frederik Zipp  wrote:
>
> Ian Lance Taylor schrieb am Dienstag, 18. August 2020 um 21:26:23 UTC+2:
>>
>> What would it mean to permit any type as a constraint?
>
>
> Each type would match exactly the same types it would match in a plain old 
> function parameter list:

Well, that's assignability.


>> I actually looked into this, to see if we could say that any type
>> could be used as a constraint, and say that a type parameter
>> constraint would permit any type argument that is assignable to the
>> constraint type. Unfortunately that leads to some odd behavior. If
>> we use a named type as the constraint, it may have methods. But we
>> can use a corresponding type literal as a type argument. That would
>> add methods to a type literal with no explicit type conversion.
>
>
> But isn't that already the case with normal function parameters?
>
> package main
>
> type S struct{}
>
> func (s S) M() {}
>
> func F(s S) {
> s.M()
> }
>
> func main() {
> // no explicit type conversion from struct{} to S
> F(struct{}{})
> }

Yes, but here you are assigning the value struct{}{} to the type S.
That's not how type arguments work: type arguments are not assigned to
type parameters.  Instead, the body of a generic function or type is
instantiated with the type argument.  In a generic function, rather
than assigning a value struct{}{} to type S, we are replacing
instances of S in F with struct{}.  But struct{} has no methods.  So
can you call method M on an argument whose type is the type parameter?
 Why or why not?


>> Similarly, if we use a type literal as a type, we can use a defined
>> type as a type argument. But the generic function could assign the
>> type parameter to some other defined type, and now we have a generic
>> function that could not be compiled if we simply substituted the type
>> argument for any instance of the type parameter.
>
>
> Same here:
>
> package main
>
> type S struct{}
>
> func (s S) M() {}
>
> func F(s struct{}) {
> var x S = s
> _ = x
> }
>
> func main() {
> // no explicit type conversion from S to struct{}
> F(S{})
> }

Same answer.  Instantiation is not assignment, so is assignability the
right rule for constraint satisfaction?


>> And I don't see what we gain by following that path.
>
>
> It would mostly be for the sake of consistency, and as a justification for a 
> hypothetical sum type like `anyof` (as a replacement for type lists in 
> interfaces) to be usable as a constraint.

Fair enough.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUVOm6UJgbKwC-dc_jnoAn3ku-MjvrRSyXnOH7kPVCx2w%40mail.gmail.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Ian Lance Taylor schrieb am Dienstag, 18. August 2020 um 21:26:23 UTC+2:

> What would it mean to permit any type as a constraint? 
>

Each type would match exactly the same types it would match in a plain old 
function parameter list:

type MyStruct struct{}
func (s MyStruct) M() {}

== Type parameter list ==

[T int] // matches 1 type; useless, just for the sake of consistency
[T MyStruct]  // matches MyStruct and 
struct{}; useless as well
[T struct{}] // matches MyStruct and 
struct{}; useless as well
[T interface{String() string}]
[T anyof{float32, float64}] // replacement for type lists in the current 
draft

== Plain old function parameter list ==

(x int) // matches 1 type
(x MyStruct)  // matches MyStruct and 
struct{}
(x struct{}) // matches MyStruct and 
struct{}
(x interface{String() string})
(x anyof{float32, float64}) // maybe in the future

 

> I actually looked into this, to see if we could say that any type 
> could be used as a constraint, and say that a type parameter 
> constraint would permit any type argument that is assignable to the 
> constraint type. Unfortunately that leads to some odd behavior. If 
> we use a named type as the constraint, it may have methods. But we 
> can use a corresponding type literal as a type argument. That would 
> add methods to a type literal with no explicit type conversion. 
>

But isn't that already the case with normal function parameters?

package main

type S struct{}

func (s S) M() {}

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

func main() {
// no explicit type conversion from struct{} to S
F(struct{}{})
}

https://play.golang.org/p/gDQfYUbe74w
 

> Similarly, if we use a type literal as a type, we can use a defined 
> type as a type argument. But the generic function could assign the 
> type parameter to some other defined type, and now we have a generic 
> function that could not be compiled if we simply substituted the type 
> argument for any instance of the type parameter. 
>

Same here:

package main

type S struct{}

func (s S) M() {}

func F(s struct{}) {
var x S = s
_ = x
}

func main() {
// no explicit type conversion from S to struct{}
F(S{})
}
 

> And I don't see what we gain by following that path. 
>

It would mostly be for the sake of consistency, and as a justification for 
a hypothetical sum type like `anyof` (as a replacement for type lists in 
interfaces) to be usable as a constraint.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/86a3a82d-6f63-4efe-b72b-81bd1efabfa1n%40googlegroups.com.

Re: [go-nuts] New linker

[Amnon]

Ian, Than - thanks for the info and the hard work.
Looking forward to putting the new linker through its paces!

On Tuesday, 18 August 2020 20:35:54 UTC+1, Ian Lance Taylor wrote:
>
> On Sat, Aug 15, 2020 at 11:49 PM Amnon > 
> wrote: 
> > 
> > Austin's doc refers to your idea of a new object format for the 21st 
> century. 
> > Has anyone developed that? 
>
> No, that is still just a thought. 
>
>
> > As someone who has been writing linkers since 1988, (most famously the 
> Gold linker), and who has a fair 
> > number of commits on the dev.linker branch,  do you have any insights 
> into the new linker project 
> > which would be interesting to share with the world? 
>
> Thanks for the praise.  Sorry to say that I don't have any particular 
> insights.  I think the new linker has been great work, but I 
> personally was only peripherally involved.  I read the design doc, and 
> that's 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a63cfb61-eb91-4a12-8132-bc3c8094a760o%40googlegroups.com.

[go-nuts] Help: Encrypting and Decrypting ASCII armor PGP Messages with golang.org/x/crypto/openpgp

[Samuel Lorch]

Hi,


i have been trying to decrypt and encrypt ASCII armor PGP Messages that i 
receive and send to a API.


I Wrote a function for decrypting messages and another one for encrypting 
messages. The Decrypting function Works and i can decrypt the API's 
messages. But My encrypt function Seems to be broken as Neither the API or 
my decrypt function can decrypt the Messages encrypted by my encrypt 
function.


Decrypting the encrypted messages from my encrypt function always result in 
the following error: 

"Error reading message: openpgp: unsupported feature: unknown 
SymmetricallyEncrypted version"


I have uploaded a example to the Go Play Ground : 
https://play.golang.org/p/JhhZ4xWWYvn


Any help is Appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/77b2200b-661e-4e24-b05e-56ccc88613e5o%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

['Axel Wagner' via golang-nuts]

On Tue, Aug 18, 2020 at 6:00 PM Frederik Zipp 
wrote:

> axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um
> 17:44:16 UTC+2:
>
>> I think in the overwhelmingly common case (a type-list being a list of
>> identifiers or short type-constructors like channels or slices), having a
>> line per item takes up a lot of vertical real-estate for little use.
>>
>
> Both options, single line and multi-line, are still available with curly
> braces and semicolons
>

Currently, gofmt normalizes struct and interface declarations to a
multi-line format.

Even if it didn't do that here, the extra {} would be gratuitous - they
serve no purpose in the grammar and add no readability.

The only reason in favor seems to be to then "embed" a new kind of
type-literal. Now, first, I don't think `type` is the right term for that
new declaration - it seems very weird and unexpected to me, to use `type X
type { … }` to declare a sum-type. It should really be `enum`, `sum`,
`anyof`,… or something else making the nature of that type clear (like
`struct` and `interface` already do). We could, of course, use any of those
as a new keyword for type-lists as well, eating the cost of introducing a
new keyword.

So, let's say we change the design to use `anyof` or something for
type-lists instead. And let's say we introduce a new kind of `anyof` type,
so we can view a type-list as an embedding of an `anyof`-literal. That
would still be weird, I believe. You would now have three connected things:

1. `anyof` declarations, only usable as types
2. `interface` declarations containing only methods, usable as constraints
and types
3. `interface` declarations containing methods and type-lists ("embedded
`anyof`s), only usable as constraints

This gives `interface` a very weird standing, IMO. It also seems strange to
only allow the third as constraints, once we've solved the zero-value
issues - I can't think of any logical reason to exclude it, just because it
*also* specifies methods. Allowing them to be used as types and/or allowing
`anyof` to be used as constraints (to resolve the weird special standing of
`interface` in this scenario) OTOH puts us in the situation that there are
multiple equivalent ways to write the same thing. `type X anyof { … }`
would be equivalent to `type X interface { anyof { … } }`.

Really, in that situation, it seems simpler to just remove `anyof`
declarations and simply allow any `interface` declaration to be used as
both a type *and* a constraint. The `anyof` declaration doesn't add any
expressive power. So we might as well avoid the detour and not introduce
`anyof` declarations at all. Which, as a bonus, means we can avoid
introducing the keyword and stay with `type` for type-lists. Which leaves
us in the situation from the design draft - just that we have to add the
ability to use `interface`s with type-lists as types.

In short: I both think a) the syntax is bad, which goes on the contra-list
and b) the reasons to do so are unconvincing, so there isn't anything in
the pro-list. At least as far as I'm concerned.

, but in the multi-line case you do not have to manage trailing commas, and
> the first line containing type(s) is not indented differently than the
> following lines.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b2cfd94c-50d0-48df-b371-b018c08b4a23n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGDHPBL_NVCr6J%2B727Feq-i6bweSZcNHGVhdBSQx7gBKA%40mail.gmail.com.

Re: [go-nuts] Re: Why we don't have simple throws error statement

[Denis Cheremisov]

Even worse: no idea where the error actually happened.
вторник, 18 августа 2020 г. в 13:33:54 UTC+3, semi...@gmail.com: 

> Another idea, if we use blank identifier for errors then throws statement 
> catch these with caller function name.
>
> func printSum(a, b, c string) error { 
>  throws func(caller string, err error) {
>  fmt.Println("caller:", caller, err)
>  return err
>  }()
>
>  x, _ := strconv.Atoi(a)
>  y, _ := strconv.Atoi(b) 
>  z, err := strconv.Atoi(c)
>  if err != nil {
>  return err
>  }
>
>  fmt.Println("result:", x + y + z)
>
>  return nil
> }
>
> How is sound?
>
> Semih.
> On Sunday, 2 August 2020 at 11:44:43 UTC+3 Denis Cheremisov wrote:
>
>> There are two major issues with Go error handling:
>>
>>
>>1. It is not strict enough, i.e. the compiler cannot ensure error 
>>check
>>2. It is not consistent enough.
>>
>> In the first you can easily ignore an error and the compiler will let you 
>> go further. In the second, you can both
>>
>> *if err := doSomething(); err != nil {*
>> *}*
>>
>> and
>>
>> *v, err := returnSomething()*
>> *if err != nil {*
>> *}*
>>
>> *or err* would do this better for sure
>>
>> *doSomething() or err {*
>> *}*
>>
>> and
>>
>> *v := returnSomething() or err {*
>> *}*
>>
>> воскресенье, 2 августа 2020 г. в 03:55:59 UTC+3, skinne...@gmail.com: 
>>
>>> I do not consider error handling an issue but then again I tend to 
>>> either use the Doit() err{} or MustDoit(){} panic and then use  DI 
>>> (dependency injection implemented by interface) for error-handling so that 
>>> I can get an email when we get a new error. So then it would be 
>>> MustDoit(errorHandler("ConIo")){} 
>>>
>>> Actually I suppose it is an issue, I do not do error handling in Go, but 
>>> my preprocessor converts it to Go. Go error handling can do anything, the 
>>> implementation may not be clear and that may be the real problem. We can 
>>> change it by improving the language or by training programmers on 
>>> recognizing useful abstractions, may need both.
>>>
>>>
>>> On Saturday, August 1, 2020 at 1:31:54 PM UTC-5 Ian Lance Taylor wrote:
>>>
 On Sat, Aug 1, 2020 at 10:59 AM  wrote: 
 > 
 > Has anyone ever tallied the number of different forum threads related 
 to changing Go error handling ? 
 > The current method is obviously a vexing issue to many Go users, and 
 > It seems silly that this issue has never been resolved by the Go team 
 beyond maintaining the status quo... despite, IMHO, several good 
 alternatives that have been suggested on this very forum. 

 There have been many alternatives suggested, but none of them have 
 been clearly better. 

 I recently wrote a brief overview at https://golang.org/issue/40432. 

 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0dd99e65-7823-4f6b-a08d-95aa6f0ebaccn%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Frederik Zipp schrieb am Dienstag, 18. August 2020 um 19:44:05 UTC+2:

> I agree it is a weird combination. Ideally it would be:
>
> 1. `anyof` declarations containing only types, usable as constraints and 
> types
> 2. `interface` declarations containing only methods, usable as constraints 
> and types
> 3. n/a
>  
> But then Go would introduce both generics and sum types at the same time, 
> which does not seem to be feasible due to unsolved questions like the 
> zero-value issue.
>

Of course, it would be possible to allow usage of `anyof`s only as 
constraints, with the option to allow them as general types in the future. 
The cost is a new keyword, though.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/afb4ebed-25a4-456a-93b1-1a891b322343n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

['Axel Wagner' via golang-nuts]

On Tue, Aug 18, 2020 at 9:04 PM Frederik Zipp 
wrote:

> I'd argue that every type expresses a certain subset of types, not just
> interfaces. For the other types the size of the subset just happens to be 1
> (each containing just itself).
>

You can certainly argue that. Though FTR, conceptually that's a very tricky
idea - sets containing themselves lead to all kinds of contradictions.

In either case - you can view it however you prefer, of course. But simply
stating that doesn't convince other people to adopt that view.

Type lists are still a new concept. Just because they hide inside
> interfaces doesn't mean that they are not a new concept.
>

As I argued in the thread I linked above: I think just as you can argue
that constraints and interfaces are different enough to make it confusing
to unify them, you can argue that they are similar enough to make it
confusing to separate them out.

I think neither view is inherently better. Both work just fine and have
very similar up- and downsides.

On the go2go.dev branch they recently made a change to use the actual (not
> underlying) types of type list elements for interface satisfaction:
> https://github.com/golang/go/commit/af48c2e84b52f99d30e4787b1b8d527b5cd2ab64
>
>

I wasn't aware of that change, thank you. AIUI, what I said remains true
though - `interface { type int }` constrains the type-argument to have
underlying type `int`. It's just that now, `interface { type time.Duration
}` no longer allows types with underlying type `int64`, for example.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/96914146-3f4e-4972-a18a-3d6b957acb90n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHopmybxwTAhJxCBebMah2kgMNHrz%3DCME_NUjAKcV%3DKPQ%40mail.gmail.com.

Re: [go-nuts] New linker

[Ian Lance Taylor]

On Sat, Aug 15, 2020 at 11:49 PM Amnon  wrote:
>
> Austin's doc refers to your idea of a new object format for the 21st century.
> Has anyone developed that?

No, that is still just a thought.


> As someone who has been writing linkers since 1988, (most famously the Gold 
> linker), and who has a fair
> number of commits on the dev.linker branch,  do you have any insights into 
> the new linker project
> which would be interesting to share with the world?

Thanks for the praise.  Sorry to say that I don't have any particular
insights.  I think the new linker has been great work, but I
personally was only peripherally involved.  I read the design doc, and
that's 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWztg7DiYtAGpnaDA25%3DNecFEUpNSks5TxznfLs6eoygg%40mail.gmail.com.

Re: [go-nuts] New linker

['Than McIntosh' via golang-nuts]

To add to what Ian mentioned:

Many of the measures outlined in https://golang.org/s/better-linker have
been implemented at this point.  It was a multi-person effort, several
members of the Go compiler/runtime team were involved (Jeremy, Cherry,
Austin, and myself).

The new indexed object file format and the improved deadcode implementation
went into the tree in time to be included in Go 1.15.

The additional changes in Go 1.16 include better streaming of data and
relocations from object file to linker output, a rewrite of the pclntab
code, support for content-addressable symbols, and more complete cleanup of
the old legacy linker data structures (e.g. removal of sym.Symbol).

Some things mentioned in the doc that didn't get implemented include moving
to DWARF 5, and moving DWARF type generation from the linker to the
compiler.

HTH.

Cheers, Than

On Sun, Aug 16, 2020 at 12:46 AM Ian Lance Taylor  wrote:

> On Sat, Aug 15, 2020 at 11:49 AM Amnon  wrote:
> >
> > What is the best place to read about the ongoing work on the new linker?
> > With the Go 1.15 release, how far along are we with the plans?
> > What has been achieved?
> > And what is still to come?
>
> The work on the new linker is close to complete and has been merged
> into tip for the future 1.16 release (although 1.16 won't be released
> until next February).  The work is as described at
> https://golang.org/s/better-linker.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXEK_OWZxKOUieHBdoH4R0eyddu_cMf_p_udWSKgZsHdA%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EHRz5O3HvdP6xwOZyrHWKJA-Oc%2B96nMOCnB%3DmzABTYqA%40mail.gmail.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

The more I think about it the less I understand why type list should reside 
inside interfaces. I can only think of two reasons:

1) Avoid a new keyword for type lists.
2) The idea that only interfaces should be able to act as constraints.

Regarding 2): Why this artificial limitation? Why not allow all types as 
constraints? Even int. It's nonsensical, but it would be like "interface{ 
type int }" in the current draft, which is nonsensical, too. The rule would 
be simple: Any type can act both as normal type and as constraint. With the 
possible exception of `anyof`s, until there is a solution to use them as 
regular types as well.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8711bcf9-6ebe-4014-9034-d0a642078791n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 19:19:32 
UTC+2:

> 1. `anyof` declarations, only usable as types
> 2. `interface` declarations containing only methods, usable as constraints 
> and types
> 3. `interface` declarations containing methods and type-lists ("embedded 
> `anyof`s), only usable as constraint.
>

I agree it is a weird combination. Ideally it would be:

1. `anyof` declarations containing only types, usable as constraints and 
types
2. `interface` declarations containing only methods, usable as constraints 
and types
3. n/a
 
But then Go would introduce both generics and sum types at the same time, 
which does not seem to be feasible due to unsolved questions like the 
zero-value issue.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/26c88fef-3235-4107-8483-b11ff0e9aaa5n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 20:47:12 
UTC+2:

> We already have a way to express "any of a certain subset of types", which 
> are interfaces, so using them for constraints is natural.
>

I'd argue that every type expresses a certain subset of types, not just 
interfaces. For the other types the size of the subset just happens to be 1 
(each containing just itself). So every type should be usable as 
constraint. Types, constraints, ... I don't see a difference anymore. 
Constraints are just types used in the type parameter list on the left.
 

> it's about avoiding a new *concept*.
>

Type lists are still a new concept. Just because they hide inside 
interfaces doesn't mean that they are not a new concept. I'd prefer it to 
be honest and give them a name, with the possibility to use them as sum 
types in the future.
 

> No, it is neither the same, nor is it nonsensical. `interface{ type int }` 
> is any type with *underlying type* `int`, not just `int`. It adds some 
> expressive power. I'm not sure how important that expressive power is, but 
> it's more than zero.
>

On the go2go.dev branch they recently made a change to use the actual (not 
underlying) types of type list elements for interface satisfaction: 
https://github.com/golang/go/commit/af48c2e84b52f99d30e4787b1b8d527b5cd2ab64
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/96914146-3f4e-4972-a18a-3d6b957acb90n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Ian Lance Taylor]

On Tue, Aug 18, 2020 at 11:29 AM Frederik Zipp  wrote:
>
> The more I think about it the less I understand why type list should reside 
> inside interfaces. I can only think of two reasons:
>
> 1) Avoid a new keyword for type lists.
> 2) The idea that only interfaces should be able to act as constraints.
>
> Regarding 2): Why this artificial limitation? Why not allow all types as 
> constraints? Even int. It's nonsensical, but it would be like "interface{ 
> type int }" in the current draft, which is nonsensical, too. The rule would 
> be simple: Any type can act both as normal type and as constraint. With the 
> possible exception of `anyof`s, until there is a solution to use them as 
> regular types as well.

Thanks for the comment.

What would it mean to permit any type as a constraint?

I actually looked into this, to see if we could say that any type
could be used as a constraint, and say that a type parameter
constraint would permit any type argument that is assignable to the
constraint type.  Unfortunately that leads to some odd behavior.  If
we use a named type as the constraint, it may have methods.  But we
can use a corresponding type literal as a type argument.  That would
add methods to a type literal with no explicit type conversion.
Similarly, if we use a type literal as a type, we can use a defined
type as a type argument.  But the generic function could assign the
type parameter to some other defined type, and now we have a generic
function that could not be compiled if we simply substituted the type
argument for any instance of the type parameter.

I know my descriptions are rather sketchy, but the point is that we
need a really clear definition of when a type argument satisfies a
type constraint, and of what operations a type constraint permits in
the generic function.  I think we have a fairly clear understanding of
this when we permit interface types, with optional type lists, as type
constraints.  I don't think we know what it means when we allow other
kinds of types as type constraints, and I don't see an obvious path
forward.  And I don't see what we gain by following that path.

Thanks again.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUFQEo-HJvaxfrP%2B6_iSojRXZ-qzfuqYaoj6ewiUX%2BCtw%40mail.gmail.com.

Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler

[Yonatan Gizachew]

But may I know what gccgo's runtime package?

On Wednesday, August 19, 2020 at 8:52:48 AM UTC+9 Ian Lance Taylor wrote:

> On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew  
> wrote:
> >
> > Sorry I couldn't provide code to reproduce the case, but I just wanted 
> to know if there are known cases for my issue.
> > From the golang source code, in the runtime library proc.go file there 
> is this code snippet
> > 
> https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199
> > In my case, I build my go program with -buildmode=c-shared mode and I 
> loaded it dynamically to my program written in C. So as to load the runtime 
> go libraries dynamically, I preferred to use the gccgo compiler instead of 
> gc compiler. Here is how I built my go code.
> >
> > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go
> >
> > I was hoping the linker would set the islibrary flag to True and as a 
> result the main function in proc.go would return at line 202. But it wasn't 
> the case.
> >
> > I was wondering why islibrary was set false.
>
> Note that gccgo uses a different runtime package. Your link is to the
> gc runtime package, not the gccgo runtime package.
>
> gccgo sets isarchive for both c-archive and c-shared. As this is an
> internal runtime variable, it shouldn't make any difference. Does it
> ever make a difference to your code that gccgo sets isarchive rather
> than islibrary?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39b98200-4b70-4c1e-8604-b98e2cad43f4n%40googlegroups.com.

Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler

[Yonatan Gizachew]

Oh, thanks for clarification. For your question, not for now.

On Wednesday, August 19, 2020 at 8:52:48 AM UTC+9 Ian Lance Taylor wrote:

> On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew  
> wrote:
> >
> > Sorry I couldn't provide code to reproduce the case, but I just wanted 
> to know if there are known cases for my issue.
> > From the golang source code, in the runtime library proc.go file there 
> is this code snippet
> > 
> https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199
> > In my case, I build my go program with -buildmode=c-shared mode and I 
> loaded it dynamically to my program written in C. So as to load the runtime 
> go libraries dynamically, I preferred to use the gccgo compiler instead of 
> gc compiler. Here is how I built my go code.
> >
> > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go
> >
> > I was hoping the linker would set the islibrary flag to True and as a 
> result the main function in proc.go would return at line 202. But it wasn't 
> the case.
> >
> > I was wondering why islibrary was set false.
>
> Note that gccgo uses a different runtime package. Your link is to the
> gc runtime package, not the gccgo runtime package.
>
> gccgo sets isarchive for both c-archive and c-shared. As this is an
> internal runtime variable, it shouldn't make any difference. Does it
> ever make a difference to your code that gccgo sets isarchive rather
> than islibrary?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/10ab8647-5307-4351-bb5f-a30f190c6208n%40googlegroups.com.

Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler

[Ian Lance Taylor]

On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew  wrote:
>
> Sorry I couldn't provide code to reproduce the case, but I just wanted to 
> know if there are known cases for my issue.
> From the golang source code, in the runtime library proc.go file there is 
> this code snippet
> https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199
> In my case, I build my go program with -buildmode=c-shared mode and I loaded 
> it dynamically to my program written in C. So as to load the runtime go 
> libraries dynamically, I preferred to use the gccgo compiler instead of gc 
> compiler. Here is how I built my go code.
>
> $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go
>
> I was hoping the linker would set the islibrary flag to True and as a result 
> the main function in proc.go would return at line 202. But it wasn't the case.
>
> I was wondering why islibrary was set false.

Note that gccgo uses a different runtime package.  Your link is to the
gc runtime package, not the gccgo runtime package.

gccgo sets isarchive for both c-archive and c-shared.  As this is an
internal runtime variable, it shouldn't make any difference.  Does it
ever make a difference to your code that gccgo sets isarchive rather
than islibrary?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWXwH4CQE65LcqCwXYXeViSs5-9GexBNH0C%2B2ktAVntmA%40mail.gmail.com.

Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler

[Ian Lance Taylor]

On Tue, Aug 18, 2020 at 6:20 PM Yonatan Gizachew  wrote:
>
> But may I know what gccgo's runtime package?

https://go.googlesource.com/gofrontend/+/refs/heads/master/libgo/go/runtime/
https://go.googlesource.com/gofrontend/+/refs/heads/master/libgo/runtime/

Ian


> On Wednesday, August 19, 2020 at 8:52:48 AM UTC+9 Ian Lance Taylor wrote:
>>
>> On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew  wrote:
>> >
>> > Sorry I couldn't provide code to reproduce the case, but I just wanted to 
>> > know if there are known cases for my issue.
>> > From the golang source code, in the runtime library proc.go file there is 
>> > this code snippet
>> > https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199
>> > In my case, I build my go program with -buildmode=c-shared mode and I 
>> > loaded it dynamically to my program written in C. So as to load the 
>> > runtime go libraries dynamically, I preferred to use the gccgo compiler 
>> > instead of gc compiler. Here is how I built my go code.
>> >
>> > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go
>> >
>> > I was hoping the linker would set the islibrary flag to True and as a 
>> > result the main function in proc.go would return at line 202. But it 
>> > wasn't the case.
>> >
>> > I was wondering why islibrary was set false.
>>
>> Note that gccgo uses a different runtime package. Your link is to the
>> gc runtime package, not the gccgo runtime package.
>>
>> gccgo sets isarchive for both c-archive and c-shared. As this is an
>> internal runtime variable, it shouldn't make any difference. Does it
>> ever make a difference to your code that gccgo sets isarchive rather
>> than islibrary?
>>
>> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/39b98200-4b70-4c1e-8604-b98e2cad43f4n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVDT06L3RDmwChTJkXmQC5OkR5KkO%3DwH%3DTcjdJrYY5sRA%40mail.gmail.com.