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:
>
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, _ :=
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>>
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
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
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
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
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
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
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
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
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
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
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
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
>
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
29 matches
Mail list logo
