Re: [go-nuts] Re: A proposal for generic in go

[Andrew Mezoni]

>>  I would also like to point out again that I am not arguing in favor or 
against the C++ or the Java way. I am simply trying to get you to answer 
the question which of the two you are proposing.

Neither one nor the other.
Only the "Go way".
And I am did not propose.
I am only try bring understanding that Go already partially ready for that.

-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> That there is an indirection in the struct doesn't mean that a function 
doesn't need to know the size of the memory it is allocating for a bucket.

Your judgement are now incorrect.
Obtaining the size of the of the type is not so hard at runtime.
It always known from `rtype`

This is how map allocates buckets.
It creates an array of the type `t.bucket`.
Where `t` is `mapType` and  the `bucket` is a field in this type which 
specifies the the better type of storing buckets.

if h.buckets == nil {
h.buckets = newarray(t.bucket, 1)
}


How new array know the size?

This is easiest question in the world.

Answer is: From a given type.


// implementation of make builtin for slicesfunc newarray(typ *_type, n 
uintptr) unsafe.Pointer {
flags := uint32(0)
if typ.kind != 0 {
flags |= flagNoScan
}
if int(n) < 0 || (typ.size > 0 && n > _MaxMem/uintptr(typ.size)) {
panic("runtime: allocation size out of range")
}
return mallocgc(uintptr(typ.size)*n, typ, flags)
}


Look how passed the `key` into the `map` method `get` (mapaccess).
It passed as the unsafe.Pointer.

func mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {


P.S.


The `map` is very well oprimized in Go language (it has more than one method 
for different groups of types).

But this does not means that the code generated for use "a single method for 
every groups of types" approach would be much more slower.

-- 
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: A proposal for generic in go

[Andrew Mezoni]

Can I ask the question out of turn?
Ok. I ask.
What wrong in Java way?
What wrong in C# way?
Of course, they have a boxing/unboxing concepts.
Does this means that boxing/unboxing is very, very, very slow operations 
and should not be used even in Java or in C#?
But they used. They used at least in generics programming in the languages.
Does this means that generics programming in these languages are very, 
very, very slow?
Does this means that generics programming in other languages are very, 
very, very fast?
Generics programming are always compromise between the performance and 
universality.
Where universality always means an usability.

C++ way is out of the scope.

@Ian Lance Taylor
Add an additional reserved field into the potential generic types and this 
will allows to starts some experiments with implementing transpilers from 
the "Go.next" to the "Go".

Eg.

type structType struct {
rtype
fields []structField
reserv unsafe.Pointer // place for the extra info about 
generic/parametrized type
}

type interfaceType struct {
rtype
methods []imethod // sorted by hash
reserv unsafe.Pointer // place for the extra info about 
generic/parametrized type
}

-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> How does the generic function know the size of the return value?

All your judgement are not correct only because you ask not a correct 
questions.

They return pointers to appropriate values.
Or you really think that the `map` also returns a value instead of pointer?
How it (map) can know the size of the return value
The `map` in Go language also generic type.

Caller (parametrized code):

var m map[Foo]Baz
...
v := m[Foo{}]

Callee (generice code):

// mapaccess1 returns a pointer to h[key].  Never returns nil, instead// it 
will return a reference to the zero object for the value type if// the key is 
not in the map.// NOTE: The returned pointer may keep the whole map live, so 
don't// hold onto it for very long.func mapaccess1(t *maptype, h *hmap, key 
unsafe.Pointer) unsafe.Pointer {


Returned value will be obtained in parametrized code (where m is map[Foo]Baz) 
from the pointer because both (caller and  callee which is instance of the 
map[Foo]Baz) operates with the values of the same types.

The `map` does not know the types and its sizes. It only know that it 
instantiated (by the type argements) at the runtime "to be ready to work for 
these types".

This approach is called "generices programming" and it used in Go language in 
the following types:

- Channels

- Slices

- Maps


P.S.

// NOTE: The returned pointer may keep the whole map live, so don't// hold onto 
it for very long.


This note not for the programmers. This not for the developers.

This is because programmers always gets a value from the dereferenced pointers 
but developers can call this function directly.

-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> I believe you've made a mistake here, elem needs to be *T , not T

This was just an abstract example.
I just wanted to say that if someone want to try implement a transpiller of 
the "Go.next" to the "Go" then the better way to represent the data of the 
different types (which are specified by the type arguments) in parametrized 
types is to use "unsafe.Pointer's".

Eg

type slice struct {

array unsafe.Pointer
len   int
cap   int
}


type sliceType struct {
rtype
elem  *rtype
}


// arrayAt returns the i-th element of p, a C-array whose elements are

// eltSize wide (in bytes).func arrayAt(p unsafe.Pointer, i int, eltSize 
uintptr) unsafe.Pointer {
return unsafe.Pointer(uintptr(p) + uintptr(i)*eltSize)
}


This means that "unsafe.Pointer's" used everywhere for represent data of 
any kind.
That's all I want to say.

-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> Now imagine that T=int8

Generic struct always has the same size only because it uses pointers.

type S  struct {
  elem T
  arr []T
}

Is the same as the following struct.

type S  struct {
  elem unsafe.Pointer
  arr []unsafe.Pointer
}

This is because it is designed to be universal.

You may ask: Why use "unsafe.Pointer" instead of the "interface{}?".
My answer is that the "unsafe.Pointer" has less size ().
Size of the "unsafe.Pointer" is a size of "uintptr".
And size of the "interface{}" is a size of the following struct:

struct emptyInterface {
  typ *rtype
  data unsafe.Pointer
}

This means, if the "emptyInterface" (a.k.a "inteface{}") is universal 
structure, and "inteface{}" uses "unsafe.Pointer" for "data" field then why 
other universal (parametrized) type (eg. generic struct) should use other 
approach?

If the information about the type arguments must be strored directly into 
the "rtype" structure then why duplicate them in each field?
The "duplicate them" means use "interface{}" instead of the 
"unsafe.Pointer".

Moreover, it is easier to work with the "unsafe.Pointer" than with the 
"interface{}".

The "interface{}" in Go language means a "boxed" value.
This is convenient, but it adds overhead in comparison with 
the "unsafe.Pointer".


-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> The fact still remains that unlike a lot of other proposed languages 
additions that are immediately dropped, generics are still open for 
discussion by the language developers themselves. 

I think that the problerm only in the Go developers brcause them even does 
try to implement them experimentally.
That is so called "hidden" implementation when the runtime engine supports 
the feature but compiler does not.
That is, available for testing only through the reflection but without 
grammar specification on that how to declare and use time at compile time.
As for me, they should have them (support of the generic types) in the 
runtime engine and in the reflection for the testing purpose but does not 
introduce them until they not decide that them are ready for real use.

-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> The version without generics is necessary to compare how well a 
particular generics approach improves the current language and code.

I am sorry but this is obviously that any useful feature (in the context of 
solving problems) improves the current language and code.
Another question: how new (version of the) language will look cosmetically 
with this newly added feature.

I found that the second question here more important then the first.

It is obviously correct that the code with a generics (in appropriate 
place) would be more useful then other code.
But here I undestand one interesting thing which states: Some obviously 
useful feature can significantly spoil the overall picture of language.

For me this is very strange only because even a C language also has been 
improved after when it initially was introduced.

In the years following the publication of K C, several features were 
added to the language, supported by compilers from AT and some other 
vendors. These included:

   - void  functions (i.e., 
   functions with no return value)
   - functions returning struct 
    or union 
    types (rather 
   than pointers)
   - assignment 
    for struct 
data 
   types
   - enumerated types 


C99 introduced several new features, including inline functions 
, several new data types 
 (including long long int and a 
complex type to represent complex numbers 
), variable-length arrays 
 and flexible array 
members , improved 
support for IEEE 754  floating 
point, support for variadic macros 
 (macros of variable arity 
), and support for one-line comments 
beginning with //

The C11 standard adds numerous new features to C and the library, including 
type generic macros, anonymous structures, improved Unicode support, atomic 
operations, multi-threading, and bounds-checked functions. 

P.S.

I guess I should think that this is very bad, because my first acquaintance 
with the language began with the ZX-Spetrum and continued with the Borland 
Turbo C.

Indeed, the C language is now looks much worse cosmetically than before. 
But should I regret it?
Maybe...

-- 
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: A proposal for generic in go

[andrew . mezoni]

>> You are not bringing anything new to the table here, except the attempt 
to insult my intelligence, apparently.
>
>
I do not have any claims to anyone personally.
I only defend my own point of view.

P.S.

Also I don't love to see or use some (not my own) code which written like a 
mess.
If I cannot understand some code then this does not means that this code is 
bad.

But if I know that a some code has been written carelessly and can be 
written more diligently then it gives me a negative reaction on that work 
(if there was no reason to write it carelessly).

That is, write code once and and use it everywhere.
Or more precisely, write (high quality and reusable) code once and and use 
it everywhere (and give the possibility to use it to everyone).

The generics programming are very good suit for that.

In the simplest definition, *generic programming* is a style of computer 
programming  in which 
algorithms are written in terms of types *to-be-specified-later* that are 
then *instantiated* when needed for specific types provided as parameters 
. 

The term *generic programming *describes a programming paradigm whereby 
fundamental requirements on types are abstracted from across concrete 
examples of algorithms and data structures and formalised as concepts, with 
generic functions implemented in terms of these concepts, typically using 
language genericity mechanisms as described above.

P.S.

I am sorry but here we discuss mostly about the advantages and 
disadvantages of the generic programming (of course, in Go language).
Here we do not discuss: How to coding in Go language without generic 
programming.
I think that it should be different topic with appropriate title.

-- 
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: A proposal for generic in go

[andrew . mezoni]

Sorry for typo and possible spam but correct example here:

type Foo interface {
  Get(key K) V
  Set(key K, val V)
}
func foo() (int, Foo) {

  // Typo: foo := {}
  foo := {}
  // ...
  foos := []Foo{}
  // ...
  k := "London"
  // ...
  return 55, foo2(foos, 55, k)
}
// This code is type safe and reusable
foo2 (foos []Foo, i int, key K) (V, Foo) {
  foo := foos[i]
  return foo.Get(key), foo
}



-- 
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: A proposal for generic in go

[andrew . mezoni]

>> perfectly type safe.

Perfectly type safe but not perfectly reusable.

What If we slightly complicate the task?

Now is my code and I want to see on your code exampe (perfectly type safe 
but and perfectly reusable)

type Foo interface {
  Get(key K) V
  Set(key K, val V)
}
func foo() (int, Foo) {
  foo := {}
  // ...
  foos := []Foo{}
  // ...
  k := "London"
  // ...
  return 55, foo2(foos, 55, k)
}
// This code is type safe and reusable
foo2 (foos []Foo, i int, key K) (V, Foo) {
  foo := foos[i]
  return foo.Get(key), foo
}

-- 
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: A proposal for generic in go

[andrew . mezoni]

>> What I mean is that most people who have followed the past generics 
discussions already know it's possible to implement them with efficient 
memory use and performance. So they don't need to worry much about that. 

Thank you for explanation.

>> can they be implemented without making Go a much more complex language 
than it is now

What is a measure of the syntax complexity in the Go language.
What this means and how they should be measured such a relative criteria?
- Much more complex
- More complex
- Slightly more complex
- Little bit more complex

Also how you personally measure these cognitive loads?

1.Sample (pattern)

type KeyValuePair interafce {
  key interface{}
  val  interface{}
}

2.Sample (pattern)

type KeyValuePair interafce {
  key K
  val  V
}

What about that a value of the #2 sample is more complex than #1 sample on 
the 146%?
With permissible error of no more than 5%.

I think that possible we should to start a discussion about that problem 
(complexity measurement of the Go language perception).

I'm not kidding.

-- 
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: A proposal for generic in go

[andrew . mezoni]

>> increase in cognitive load to decipher chains of type definitions.

Sorry, but who are members of this mail lists?
This is a first time when I hear about such loads such as the `cognitive 
load`.
Also I am possible here a single person who does not know anything about 
the `cognitive load to decipher chains of type definitions`.
I am mostly business man and a programmer just for my own requirements.
I love to implements parsers, code generators, some effective algorithms 
for solving some problem at the most effective time.
Also my work includes a diagnose the failures and locate them.
And I want to apologize for my illiteracy (thick-headed), but I do not 
really was expecting that all members of this mail list worry mostly about 
the ` increase in cognitive load to decipher chains of type definitions` 
and don't worry about other things.
I am sorry.

-- 
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: A proposal for generic in go

[andrew . mezoni]

>> I am not saying that generics is bad, but I am questioning whether 
generics is necessary.

Please, do not panic.
If you worry about the following things:
- Generated code will grow when used generics
- Generated code will be more complex when used generics
- Execution performance will slow down when used generics
- Memory consumption will grow when used generics

I can say you.
- Generated code will NOT grow when used generics
- Generated code will NOT more complex when used generics
- Execution performance will NOT slow down when used generics
- Memory consumption will NOT grow when used generics

They are so arranged that they are universal for all uses cases and does 
not require a significant changes in the following things:
- Compilers
- Runtimes
- Reflections

Most of the type checks will be performed at the compile time only because 
the Go language is statically typed language.
Most of the type instances (instances of the generic types which will be 
created at runtime) will be stored for the further reuse (they will be not 
created again and again but they will retrieved from the hidden static 
variables, so called lazy getters).

Only when used reflection then they (newly created type instances) can get 
some overhead but just a little bit more then with non-generic types.

Generic types is not evil, nor complex.
They are still the same types but only with the parameters (this is single 
kind of complexity which for me is not complexity at all) and they are 
variative (but this is not a complexity this is just a rules).

-- 
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: A proposal for generic in go

[andrew . mezoni]

>> I was one of the generics supporters for Go in this forum, but now I am 
not so sure.

But why?
Generic types is the same types as and the regular types.
Difference only in that the regular types does not have a parameters but 
generic types are always have at least one parameter.
This is why they are called generic (universal) types.
The same as you don't worry about that the function can have a parameters 
why you should worry about that the type can have a parameters?
When for types allowed to have parameters then this get a some benefits:
1. Generice types can be "configured" by some requirements (by their 
parameters)
2. Generice types can have a restrictions (eg. each parameter can have its 
own upper type bounds)
3. Generic types are universal types

Eg. Trivial example

type KeyValuePair struct {
  key K
  val V
}

You can use this type everywhere since it is universal type.

Below is not the same type (because in generic type system K != V, but here 
interface{} == interface{}):

type KeyValuePair struct {
  key interface{}
  val interface{}
}

Because power of the generic types in that the they are variative:
- Covariant
- Contrvariant
- Invariant

And they, of course, can have a 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.

[go-nuts] Re: A proposal for generic in go

[andrew . mezoni]

>> While later I realized that we still need some parameter check in the 
callee code to satisfy the interface matching (the generic version of each 
function in my proposal).

A am sorry but your judgements is not correct.
Here is a proofs:
1. It is redundant to perform check of the correctness of the assignments 
after when assignement already made.

Eg.

val i int
i = 0
// It is redundant to perform check the correctness of the assignments of 
`i` after when assignement of `i` already made.

2. Fucntion is a callable piece of code which CAN have initial variables 
(function parameters) which SHOULD be assigned (via function arguments) 
before function invocation.

Of course, these parameters can be explicit and implicit.
Eg. receiver of the method is an implicit parameter but it still a 
parameter (function variable which would be assigned before function 
invocation implicitly by the compiler, or by the reflection construction).

That is, this code is equilvalent.

var i int
i = 0
// other code, `i` already assigned

func foo(i int) {
  // other code, `i` already assigned
}


3. Also you should to know that in a generic type system (type sytem with 
the generic types) each type is potentialy a generic type.
Here is a proof.

Each type in a generic type system looks like a function.
Type can have a [0..~] number of parameters which are declared by the type 
declaration and whose parameters can be assigned by the type arguments. If 
arguments omitted then parameters assigned to default values (types).


The same as the funtions.

// Declare type with 2 parameters, K and V
type Type {}

// Declare type with 2 bounded parameters, K and V
type Type1 {}

// Instantiate new type with a specified arguments (the same as the 
function invocation)
// For simplicity we can imagine the following auto generated code
// if *__staticType1021 == nill {
//   *__staticType1021 = __createGenericType(__getType(Type1), 
__getType(string), __getType(bool))
//  That is, call to __createGenericType(*t RType, args... *RType)
// }

// foo := __newobject(*__staticType1021)

foo := Type1()

Another story when we use generic type on the callee side.

func (t *Type1) foo(key K) V {
  // Here compiler always assume that the type of `t` is a generic type 
`Type1` with a correctly assigned type arguments.
  // Assigned arguments does not need to re-check 
  // ___type0 := __getTypeOf(t)
  // Here is enough (since type are generic) rely only on that the each 
type argument bound to the type parameter
  ...
}


-- 
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: A proposal for generic in go

[andrew . mezoni]

Overhead at runtime will be not very big;
1. Generate each time an instance of specific generic type with arguments
2. Perform generic specific type checks before any kind of an assignements

1. The first overhead can be reduced (eleminated) by the static code 
generation of specified generic types with storing them in special place

Eg.

foo := Foo{}

Since this code is static (which means that at runtime the arguments 
(string and int) remains unchanged then this type (Foo) can 
be canonicalized (I can also say "hashed" but canonicalized is more 
precisely). pre-generated by the compiler and stored (to avoid re-creating 
it each time at runtime) for further use.

2. The second overhead can be reduced (eleminated) by the static code 
generation when compiler can compute types (used in assignments).

Since specific generic type is know at compile time then generic type 
checks (the same as regular, non generic) can be performed at compile time

-- 
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: A proposal for generic in go

[andrew . mezoni]

As for me then everything is much more simple if Go language (as the 
starting point) will  introduce a non-reified generics.
Non reified generics does not requires a complex runtime support (static 
code which was generated by the compiler will be enough).
Type checking of the type arguments performed at the compile time on the 
calller side (sender code).
The callee side (receiver code) remains unchanged as it is currently is.
This has some benefits:
1. This is a starting point (but not a no dead end) and point for a later 
enhancements
2. Does not requires significant changes in the compiler (codegen)
3. Does not requires significant changes in the runtime (engine)
4. Does not requires significant changes in the type system (just to add a 
few additional fields into the interface type presentation)
5. Does not requires significant changes in the reflection (just to adapt 
for slightly extended type presentation)

Because they (generic types) will be not reified on the callee side 
(receiver code) then compiler can generate the same code as it generates 
currently.
Only callers side will perform generic type checks before assignments of 
values with generic types and vice versa (to variables, constants, function 
and methods arguments).

That is.

type Foo struct {
}

func (s *Foo) Get(key K) (val V) {
  // Here is generated unchanged code
  // The same as for non generic use
}

func some() {
  foo := Foo{}

  // Generated by the compiler
  // _typ := _getRTypeOf(foo)
  // _typ.isGeneric = true
  // _typ.genParams = [2]_GenParam
  // _typ.genParams[0] = &_GenParam{key: "K", val: _getRType(interface{}}
  // _typ.genParams[0] = &_GenParam{key: "V", val: _getRType(interface{}}
  // _typ.genArgs = [2]*_RType{}
  // _typ.genArgs[0] = _getRType(string)
  // _typ.genArgs[1] = _getRType(int)
  // Also compiler statically performs type check bounds of the type 
arguments to type parameters assignments (if type bounds specified)

  var key interface{}
  key = bool

  // Generated by the compiler (safe guard)
  // _temp0 := key
  // _checkGenericArg(_typ, 0, temp0)
  // _temp1 := foo.Get(key)

  val := foo.Get(_temp0)
}

That is, the compiler always (if it cannot compute the type at compile time 
and cannot to check them statically) inserts "safe guards" type check 
before any kimd of an assignments.
The `_checkGenericArg(_typ, index, key)` also performs the checks to type 
parameter bounds (eg. for Foo) for a given index of the 
type parameter and argument.

Callee code does not performs any type checks on incomming parameters.
It always think that incomming parameters has specified type.
That is, if type bounds ommitted then specified type is interface{}
If type bounds specified then specified type is itself

Eg.

type Type1 struct {
}

type Type2 struct {
}

func(t *Type1) foo(val E) {
}

func(t *Type2) foo(val E) {
}

Generated as the following (that's easy)

func(t *Type1) foo(val interface{}) {
}

func(t *Type2) foo(val int) {
}

-- 
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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[andrew . mezoni]

>> Keeping a a pointer in a uintptr as a "reference" to something is safe 
iff it will never be casted back to a pointer. I think this means that the 
safe case is useless.

Storing any reference (read: address) of Go instance is unsafe because 
after when this operation ends then a stored address (as the uintptr value) 
can become not legal because any instance can be moved by GC into the other 
place (read: address).
This is a reason why recommended to perform such operation inside a sigle 
expression.

Eg.

VALID
e := unsafe.Pointer(uintptr(unsafe.Pointer())

NOT VALID
addr := uintptr(unsafe.Pointer()
e := unsafe.Pointer(addr)

Explained
addr := uintptr(unsafe.Pointer()
// Here stored `addr` already can be non valid
e := unsafe.Pointer(addr)

-- 
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.