Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Fri, Aug 26, 2016 at 8:17 PM, T L wrote: > > On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote: >> >> Hi, >> >> Generally speaking, you may find it a bit of struggling if you are trying >> to write Go code in an attempt to emulate *how* other languages can do, or >> to argue with the compiler about how a fresh learner would come to think in >> the first place. A tip for making the learning/adaption process smoother is >> to focus on *what* you want to achieve in the problem domain (instead of >> language domain, like fighting the compiler). >> >> Veteran gophers would be most helpful if you ask about the specific >> functionalities or features you are trying to build. It's very likely that >> the language problems you encountered don't exist at all in other >> well-explored approaches. >> > > And it is very appreciated if you can show the behind reason for "why can't > []Age be converted into []int". You have gotten several different answers to that question. What kind of answer would you find satisfactory? Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Saturday, August 27, 2016 at 11:40:20 AM UTC+8, Ian Lance Taylor wrote: > > On Fri, Aug 26, 2016 at 8:17 PM, T L > > wrote: > > > > On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote: > >> > >> Hi, > >> > >> Generally speaking, you may find it a bit of struggling if you are > trying > >> to write Go code in an attempt to emulate *how* other languages can do, > or > >> to argue with the compiler about how a fresh learner would come to > think in > >> the first place. A tip for making the learning/adaption process > smoother is > >> to focus on *what* you want to achieve in the problem domain (instead > of > >> language domain, like fighting the compiler). > >> > >> Veteran gophers would be most helpful if you ask about the specific > >> functionalities or features you are trying to build. It's very likely > that > >> the language problems you encountered don't exist at all in other > >> well-explored approaches. > >> > > > > And it is very appreciated if you can show the behind reason for "why > can't > > []Age be converted into []int". > > You have gotten several different answers to that question. > > What kind of answer would you find satisfactory? > > Ian > No one have answered what is the behind reason for "why can't []Age be converted into []int" yet. I don't think "rules disallow it, so it can't" is a good answer. -- 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: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Fri, Aug 26, 2016 at 8:52 PM, T L wrote: > > On Saturday, August 27, 2016 at 11:40:20 AM UTC+8, Ian Lance Taylor wrote: >> >> On Fri, Aug 26, 2016 at 8:17 PM, T L wrote: >> > >> > On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote: >> >> >> >> Hi, >> >> >> >> Generally speaking, you may find it a bit of struggling if you are >> >> trying >> >> to write Go code in an attempt to emulate *how* other languages can do, >> >> or >> >> to argue with the compiler about how a fresh learner would come to >> >> think in >> >> the first place. A tip for making the learning/adaption process >> >> smoother is >> >> to focus on *what* you want to achieve in the problem domain (instead >> >> of >> >> language domain, like fighting the compiler). >> >> >> >> Veteran gophers would be most helpful if you ask about the specific >> >> functionalities or features you are trying to build. It's very likely >> >> that >> >> the language problems you encountered don't exist at all in other >> >> well-explored approaches. >> >> >> > >> > And it is very appreciated if you can show the behind reason for "why >> > can't >> > []Age be converted into []int". >> >> You have gotten several different answers to that question. >> >> What kind of answer would you find satisfactory? > > No one have answered what is the behind reason for "why can't []Age be > converted into []int" yet. > > I don't think "rules disallow it, so it can't" is a good answer. Many people have answered it, including me. Perhaps you missed my answer; it is here: https://groups.google.com/d/msg/golang-nuts/jDcUu4gUIRc/fX5pI66zFQAJ . So, I'm sorry, but I have to ask again: what kind of answer would you find satisfactory? Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Saturday, August 27, 2016 at 12:28:16 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Aug 26, 2016 at 8:52 PM, T L > > wrote: > > > > On Saturday, August 27, 2016 at 11:40:20 AM UTC+8, Ian Lance Taylor > wrote: > >> > >> On Fri, Aug 26, 2016 at 8:17 PM, T L wrote: > >> > > >> > On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote: > >> >> > >> >> Hi, > >> >> > >> >> Generally speaking, you may find it a bit of struggling if you are > >> >> trying > >> >> to write Go code in an attempt to emulate *how* other languages can > do, > >> >> or > >> >> to argue with the compiler about how a fresh learner would come to > >> >> think in > >> >> the first place. A tip for making the learning/adaption process > >> >> smoother is > >> >> to focus on *what* you want to achieve in the problem domain > (instead > >> >> of > >> >> language domain, like fighting the compiler). > >> >> > >> >> Veteran gophers would be most helpful if you ask about the specific > >> >> functionalities or features you are trying to build. It's very > likely > >> >> that > >> >> the language problems you encountered don't exist at all in other > >> >> well-explored approaches. > >> >> > >> > > >> > And it is very appreciated if you can show the behind reason for "why > >> > can't > >> > []Age be converted into []int". > >> > >> You have gotten several different answers to that question. > >> > >> What kind of answer would you find satisfactory? > > > > No one have answered what is the behind reason for "why can't []Age be > > converted into []int" yet. > > > > I don't think "rules disallow it, so it can't" is a good answer. > > Many people have answered it, including me. Perhaps you missed my > answer; it is here: > https://groups.google.com/d/msg/golang-nuts/jDcUu4gUIRc/fX5pI66zFQAJ . > > So, I'm sorry, but I have to ask again: what kind of answer would you > find satisfactory? > > Ian > I have read and replied your answer above. And sorry I didn't convert all aspects in that reply. > "..., which makes it hard to understand what kind of answer you are looking for, and why you are asking. Can you expand on that? " Sorry, secret now. :) Alternative answer: I'm curious on the details of Golang rules. > "You are suggesting that there is an extra rule to forbids converting []T1 to []T2 when T1 and T2 have the same underlying representation." No. I understand []T1 can't be converted to []T2 when T1 and T2 have different underlying representation. Ok, the alternative of my question is: why []T2 and []T1 have different underlying representations when T2 and T1 have the same underlying representation? > "despite the overall prohibition on converting []T1 to []T2, you are permitted to convert them exactly when T1 and T2 have the same underlying representation. That rule is much more complex than the current rule. It means that people reading Go code have to understand when T1 and T2 have the same representation." So you mean there is no implementation obstacles to allow converting []Age to []int? The prohibition is just to make people less confused. But the current prohibition make me confused, may I am not a typical gopher. -- 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: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Fri, Aug 26, 2016 at 9:46 PM, T L wrote: > >> "You are suggesting that there is an extra rule to forbids converting []T1 >> to > []T2 when T1 and T2 have the same underlying representation." > > No. I understand []T1 can't be converted to []T2 when T1 and T2 have > different underlying representation. > > Ok, the alternative of my question is: why []T2 and []T1 have different > underlying representations when T2 and T1 have the same underlying > representation? They don't. If T2 and T1 have the same underlying representation, then []T2 and []T1 have the same underlying representation. >> "despite the overall prohibition on converting []T1 to > []T2, you are permitted to convert them exactly when T1 and T2 have > the same underlying representation. That rule is much more complex > than the current rule. It means that people reading Go code have to > understand when T1 and T2 have the same representation." > > So you mean there is no implementation obstacles to allow converting []Age > to []int? That is correct. > The prohibition is just to make people less confused. I would say that it is to make the language simpler. There are fewer things that people learning the language need to understand. > But the current prohibition make me confused, may I am not a typical gopher. Why does it make you confused? On a 64-bit system, the types "int" and "int64" have the same representation. They are both 64-bit signed integers. Does it confuse you that Go rejects var v int = int64(1) ? If that does not confuse you, then the fact Go does not permit assigning from []Age to []int should not confuse you. It is the same kind of thing: in Go, different types are different. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
>
>
> Ok, the alternative of my question is: why []T2 and []T1 have different
> underlying representations when T2 and T1 have the same underlying
> representation?
>
>
There is a difference - the compiler does not split slices and find the
underlying representation of the non-slice part (example
https://play.golang.org/p/hnjNkM77h7)
package main
type T1 string
type T2 T1
type T3 []T1
type T4 T3
type S1 T1
type S2 S1
type S3 []S1
type S4 S3
func main() {
var (
t3 T3
t4 T4
s3 S3
s4 S4
r T1
)
a := T3(t3)
b := T4(t4)
c := T3(t4)
d := T4(t3)
e := T3(s3) //not allowed
f := T3(s4) //not allowed
z := S4(t4) //not allowed
//etc
r2 := S2(r)
v := S3(s3)
w := S4(s4)
x := S3(s4)
y := S4(s3)
The slice is treated as a type unto itself - that is why, in the examples
cross conversion between slice types involving S and T fail.
In the spec ( https://golang.org/ref/spec#TypeName ) types are defined. The
relevant text on underlying types is *"Each type T has an underlying type:
If T is one of the predeclared boolean, numeric, or string types, or a type
literal"*
Type = TypeName | TypeLit | "(" Type ")" .
TypeName = identifier | QualifiedIdent .
TypeLit = ArrayType | StructType | PointerType | FunctionType |
InterfaceType | SliceType | MapType | ChannelType .
In the non slice type (eg String) this corresponds to TypeName, whereas in
the slice (eg []String) example this corresponds to TypeLit (SliceType).
The language specification does not state that type literals are further
analysed for sub-type matches - so it does not happen.
I get that a common expectation is that a full recursive analysis of a
TypeLiteral *might* happen, reducing each sub-element of the TypeLiteral to
its lowest form - but it doesn't happen.
--
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: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Saturday, August 27, 2016 at 1:36:53 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Aug 26, 2016 at 9:46 PM, T L > > wrote: > > > >> "You are suggesting that there is an extra rule to forbids converting > []T1 > >> to > > []T2 when T1 and T2 have the same underlying representation." > > > > No. I understand []T1 can't be converted to []T2 when T1 and T2 have > > different underlying representation. > > > > Ok, the alternative of my question is: why []T2 and []T1 have different > > underlying representations when T2 and T1 have the same underlying > > representation? > > They don't. > > If T2 and T1 have the same underlying representation, then []T2 and > []T1 have the same underlying representation. > > > >> "despite the overall prohibition on converting []T1 to > > []T2, you are permitted to convert them exactly when T1 and T2 have > > the same underlying representation. That rule is much more complex > > than the current rule. It means that people reading Go code have to > > understand when T1 and T2 have the same representation." > > > > So you mean there is no implementation obstacles to allow converting > []Age > > to []int? > > That is correct. > > > > The prohibition is just to make people less confused. > > I would say that it is to make the language simpler. There are fewer > things that people learning the language need to understand. > > > > But the current prohibition make me confused, may I am not a typical > gopher. > > Why does it make you confused? > > On a 64-bit system, the types "int" and "int64" have the same > representation. They are both 64-bit signed integers. Does it > confuse you that Go rejects > > var v int = int64(1) > I don't think an int64 value can be converted to an int value is for they have the same underlying type. In fact, an int8 value can also be converted to an int value. "Number values can be converted to values of other number types" is totally an exception for the conversion rule. This has nothing related to the underlying types. > > ? > > If that does not confuse you, then the fact Go does not permit > assigning from []Age to []int should not confuse you. It is the same > kind of thing: in Go, different types are different. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Saturday, August 27, 2016 at 3:41:34 PM UTC+8, T L wrote: > > > > On Saturday, August 27, 2016 at 1:36:53 PM UTC+8, Ian Lance Taylor wrote: >> >> On Fri, Aug 26, 2016 at 9:46 PM, T L wrote: >> > >> >> "You are suggesting that there is an extra rule to forbids converting >> []T1 >> >> to >> > []T2 when T1 and T2 have the same underlying representation." >> > >> > No. I understand []T1 can't be converted to []T2 when T1 and T2 have >> > different underlying representation. >> > >> > Ok, the alternative of my question is: why []T2 and []T1 have different >> > underlying representations when T2 and T1 have the same underlying >> > representation? >> >> They don't. >> >> If T2 and T1 have the same underlying representation, then []T2 and >> []T1 have the same underlying representation. >> >> >> >> "despite the overall prohibition on converting []T1 to >> > []T2, you are permitted to convert them exactly when T1 and T2 have >> > the same underlying representation. That rule is much more complex >> > than the current rule. It means that people reading Go code have to >> > understand when T1 and T2 have the same representation." >> > >> > So you mean there is no implementation obstacles to allow converting >> []Age >> > to []int? >> >> That is correct. >> >> >> > The prohibition is just to make people less confused. >> >> I would say that it is to make the language simpler. There are fewer >> things that people learning the language need to understand. >> >> >> > But the current prohibition make me confused, may I am not a typical >> gopher. >> >> Why does it make you confused? >> >> On a 64-bit system, the types "int" and "int64" have the same >> representation. They are both 64-bit signed integers. Does it >> confuse you that Go rejects >> >> var v int = int64(1) >> > > I don't think an int64 value can be converted to an int value is for they > have the same underlying type. > In fact, an int8 value can also be converted to an int value. > "Number values can be converted to values of other number types" is > totally an exception for the conversion rule. > This has nothing related to the underlying types. > And another exception for the conversion rule is: 1. string values can be converted []byte values and vice versa. 2: string values can be converted []rune values and vice versa. For almost every basic rule in goalng, there are some exceptions. This is my impression for golang syntax rules. > > >> >> ? >> >> If that does not confuse you, then the fact Go does not permit >> assigning from []Age to []int should not confuse you. It is the same >> kind of thing: in Go, different types are different. >> >> Ian >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
Look at this example code from https://talks.golang.org/2012/goforc/celsius.go and you'll know why. Although the underlying type of Celsius and Fahrenheit are the same - float32. There will be no meaning if the language allow you to convert these type to the underlying type float32. What's it mean for 0 = 273.15? (273.15K = 0°C). Also, even for the Age type, I may use it for a person's age, you may use it for a virus' age. The person may live 100 years, but some virus may live only several hours. Although the underlying type is int, what does it mean when you compare a person's age with a virus' age? "A type determines the set of values and operations specific to values of that type." type Age is not the same as type int. Andrew > >>> -- 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: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Saturday, August 27, 2016 at 10:33:45 PM UTC+8, amk...@gmail.com wrote: > > Look at this example code from > https://talks.golang.org/2012/goforc/celsius.go and you'll know why. > > Although the underlying type of Celsius and Fahrenheit are the same - > float32. > There will be no meaning if the language allow you to convert these type to > the underlying type float32. What's it mean for 0 = 273.15? (273.15K = 0 > °C). > > Also, even for the Age type, I may use it for a person's age, you may use > it for a virus' age. > The person may live 100 years, but some virus may live only several hours. > Although the > underlying type is int, what does it mean when you compare a person's age > with a virus' age? > > "A type determines the set of values and operations specific to values of > that type." > type Age is not the same as type int. > In this example, in fact, values of Celsius and Fahrenheit (including float32) can be converted to other types. > > Andrew > >> -- 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: Why can't convert []T to []T2 if T2 is a copy definition of T?
Up to now, the most convincing reason is "it is to make the language
simpler" mentioned by Ian.
Maybe Ian is right. I have seen the following code in golang src:
type hmap struct {
*[2]*[]*bmap
}
Maybe sometimes, it is really hard to judge if two types have a same
underlying representation.
On Saturday, August 27, 2016 at 11:28:39 PM UTC+8, T L wrote:
>
>
>
> On Saturday, August 27, 2016 at 10:33:45 PM UTC+8, amk...@gmail.com wrote:
>>
>> Look at this example code from
>> https://talks.golang.org/2012/goforc/celsius.go and you'll know why.
>>
>> Although the underlying type of Celsius and Fahrenheit are the same -
>> float32.
>> There will be no meaning if the language allow you to convert these type to
>> the underlying type float32. What's it mean for 0 = 273.15? (273.15K = 0
>> °C).
>>
>
>> Also, even for the Age type, I may use it for a person's age, you may use
>> it for a virus' age.
>> The person may live 100 years, but some virus may live only several
>> hours. Although the
>> underlying type is int, what does it mean when you compare a person's age
>> with a virus' age?
>>
>> "A type determines the set of values and operations specific to values
>> of that type."
>> type Age is not the same as type int.
>>
>
> In this example, in fact, values of Celsius and Fahrenheit (including
> float32) can be converted to other types.
>
>
>>
>> Andrew
>>
>>>
>
--
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: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Sunday, August 28, 2016 at 12:56:37 AM UTC+8, Michael Jones wrote: > > TL, I have been confused by this thread, your similar questions, and in > fact, most of your emails—until now. > > > > When you write ‘Why can’t X’ as you often do, I have presumed that this > was a casual and imprecise form of expressing the question “what is the > reason why a different path was chosen.” Now, based on this, I see it > differently. I think you mean it literally. I imagine myself walking beside > you and you saying, “Why can’t trees be blue? Why can’t dogs have square > heads? Why can’t cars have windows in the tires? Why don’t cats and pigs > swim?” Which is to say, it seems that you are writing email as a way to > share a stream of consciousness that every aspect of reality—every choice, > decision, evolutionary outcome, taste, desire—could in fact be different in > some other place or time or circumstance. > > > > Now that the question unfolds as “Why is it not possible that X” (as you > wrote from the start) then the answer to your emails is, “It is possible,” > possible as in, “in a different language, with a different goal, on a > hypothetical computer, if the most common programmer errors were not as > they are, etc.” In engineering, nearly everything is possible. Not all of > the possibilities are good, wise, or desirable though, so I think many here > thought these other attributes were implied as part of your question. I did > before but now do not. > > > > In your spirit of “Why can’t” as in “prove that it is impossible” (of > course such proofs are impossible), I offer examples of the uncommon but > possible. > > > > > > > > A different question, “Why is X disallowed in Go,” is actually much more > educational. The example below, that was given you by amkguo, is the > example that I thought of right at first—not about “why can’t bytes be > interchangeable” but “why are Types treated as separate species.” This is a > great topic. Because of huge human experience that mixing types by concept > (adding two kinds of temperature or mass) results in unfortunate outcomes > (many!) and similar experience in debugging as the result of many > languages, C and C++ among them, doing natural-seeming invisible coercion > between types. Type coercion in specific and invisible actions generally > are a trouble area in large-scale software development. This is why the Go > team (superstars with UNIX, C, major Gnu C/C++ implementation, Plan 9, > Inferno, and maybe more importantly, careful study of common software > development problems by 10,000+ programmers Google) disallowed it during > the design of Go and instead require explicit casts (as in “var a int = 3; > b := float64(a)”), why they treat Types as non-mixing species, and why the > affordances around this are very limited. > > > > I gave a talk in Madrid about Go as a software engineering approach > assisted by a computer language. This seems a nice educational way to avoid > many of the “but C allows …” or “it should be technically possible to…” > confusions. > > > > Michael > I never deny the great work made by golang team. In fact, I'm a go lover. I just want to understand the reason for some golang syntax rules. :) > > > *From: *> on behalf of T L < > tapi...@gmail.com > > *Date: *Saturday, August 27, 2016 at 8:28 AM > *To: *golang-nuts > > *Cc: *>, > > *Subject: *Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a > copy definition of T? > > > > On Saturday, August 27, 2016 at 10:33:45 PM UTC+8, amk...@gmail.com wrote: > > Look at this example code from > https://talks.golang.org/2012/goforc/celsius.go and you'll know why. > > > > Although the underlying type of Celsius and Fahrenheit are the same - > float32. There will be no meaning if the language allow you to convert > these type to the underlying type float32. What's it mean for 0 = 273.15? ( > 273.15K = 0°C). > > > > Also, even for the Age type, I may use it for a person's age, you may use > it for a virus' age. > > The person may live 100 years, but some virus may live only several hours. > Although the > > underlying type is int, what does it mean when you compare a person's age > with a virus' age? > > "A type determines the set of values and operations specific to values of > that type." > > type Age is not the same as type int. > > > In this example, in fact, values of Celsius and Fahrenheit (including > float32) can be converted to other types. > > -- 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: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Sat, Aug 27, 2016 at 12:41 AM, T L wrote: > > I don't think an int64 value can be converted to an int value is for they > have the same underlying type. > In fact, an int8 value can also be converted to an int value. > "Number values can be converted to values of other number types" is totally > an exception for the conversion rule. > This has nothing related to the underlying types. I'm sorry, I don't understand the point you are making. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Sunday, August 28, 2016 at 11:00:53 AM UTC+8, Ian Lance Taylor wrote: > > On Sat, Aug 27, 2016 at 12:41 AM, T L > > wrote: > > > > I don't think an int64 value can be converted to an int value is for > they > > have the same underlying type. > > In fact, an int8 value can also be converted to an int value. > > "Number values can be converted to values of other number types" is > totally > > an exception for the conversion rule. > > This has nothing related to the underlying types. > > I'm sorry, I don't understand the point you are making. > > Ian > isn't the basic conversion rule is two values with a same underlying type can be converted to each other' type? (another basic conversion rule is, if T implements interface I, the values of T can be converted to values of I) The underlying types of different numeric types are different. Golang just makes an exception/convenience to make it is possible to convert the values of these types to any of these types. And there is another exception, integer values can be converted to string, this is one-direction conversion. -- 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: Why can't convert []T to []T2 if T2 is a copy definition of T?
I think that your original interpretation of TL's questions is the correct one, and the one that I read when I read all of this posts. I don't think that it's a fair characterisation that he is asking about possibility rather that design, even in the post that this was a reply to. I can understand his position entirely, and his frustration that might lead to the epic threads that we see here. When I was starting to use Go, I often asked questions about the motivation/reason behind prohibitions or approaches in Go to be answered, extremely frustrating, by references to the spec (I find understanding things unless I know why they are the way they are - see Katrina Owen's great discussion about knowledge construction and its graphical basis in "Mind the Gap" for why rationale facilitates knowledge graph growth). This has improved here, in that people now more often answer with design justifications, though still there is a cultural habit or responding with essentially that it is "because". This would have been a significantly shorter thread if there had been a clear explanation of the motivation behind slice conversion restrictions early. This could have been after about the second (certainly by fourth) post from TL where it became clear that he was asking about motivation rather than mechanics (the initial post was ambiguous). Dan On Sat, 2016-08-27 at 09:56 -0700, Michael Jones wrote: > TL, I have been confused by this thread, your similar questions, and > in fact, most of your emails—until now. > > > > When you write ‘Why can’t X’ as you often do, I have presumed that > this was a casual and imprecise form of expressing the question “what > is the reason why a different path was chosen.” Now, based on this, I > see it differently. I think you mean it literally. I imagine myself > walking beside you and you saying, “Why can’t trees be blue? Why can’t > dogs have square heads? Why can’t cars have windows in the tires? Why > don’t cats and pigs swim?” Which is to say, it seems that you are > writing email as a way to share a stream of consciousness that every > aspect of reality—every choice, decision, evolutionary outcome, taste, > desire—could in fact be different in some other place or time or > circumstance. > > > > Now that the question unfolds as “Why is it not possible that X” (as > you wrote from the start) then the answer to your emails is, “It is > possible,” possible as in, “in a different language, with a different > goal, on a hypothetical computer, if the most common programmer errors > were not as they are, etc.” In engineering, nearly everything is > possible. Not all of the possibilities are good, wise, or desirable > though, so I think many here thought these other attributes were > implied as part of your question. I did before but now do not. > > > > In your spirit of “Why can’t” as in “prove that it is impossible” (of > course such proofs are impossible), I offer examples of the uncommon > but possible. > > > > > > > > A different question, “Why is X disallowed in Go,” is actually much > more educational. The example below, that was given you by amkguo, is > the example that I thought of right at first—not about “why can’t > bytes be interchangeable” but “why are Types treated as separate > species.” This is a great topic. Because of huge human experience that > mixing types by concept (adding two kinds of temperature or mass) > results in unfortunate outcomes (many!) and similar experience in > debugging as the result of many languages, C and C++ among them, doing > natural-seeming invisible coercion between types. Type coercion in > specific and invisible actions generally are a trouble area in > large-scale software development. This is why the Go team (superstars > with UNIX, C, major Gnu C/C++ implementation, Plan 9, Inferno, and > maybe more importantly, careful study of common software development > problems by 10,000+ programmers Google) disallowed it during the > design of Go and instead require explicit casts (as in “var a int = 3; > b := float64(a)”), why they treat Types as non-mixing species, and why > the affordances around this are very limited. > > > > I gave a talk in Madrid about Go as a software engineering approach > assisted by a computer language. This seems a nice educational way to > avoid many of the “but C allows …” or “it should be technically > possible to…” confusions. > > > > Michael -- Omnes mundum facimus. Dan Kortschak F9B3 3810 C4DD E214 347C B8DA D879 B7A7 EECC 5A40 10C7 EEF4 A467 89C9 CA00 70DF C18F 3421 A744 607C -- 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: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Sat, Aug 27, 2016 at 8:26 PM, T L wrote: > > On Sunday, August 28, 2016 at 11:00:53 AM UTC+8, Ian Lance Taylor wrote: >> >> On Sat, Aug 27, 2016 at 12:41 AM, T L wrote: >> > >> > I don't think an int64 value can be converted to an int value is for >> > they >> > have the same underlying type. >> > In fact, an int8 value can also be converted to an int value. >> > "Number values can be converted to values of other number types" is >> > totally >> > an exception for the conversion rule. >> > This has nothing related to the underlying types. >> >> I'm sorry, I don't understand the point you are making. >> >> Ian > > > isn't the basic conversion rule is two values with a same underlying type > can be converted to each other' type? Yes, if by "same underlying type" you mean "identical underlying type". In the original question of why you can't convert []Age to []int, []Age and []int are not identical underlying types. > (another basic conversion rule is, if T implements interface I, the values > of T can be converted to values of I) Yes, that is true. > The underlying types of different numeric types are different. > Golang just makes an exception/convenience to make it is possible to convert > the values of these types to any of these types. > > And there is another exception, integer values can be converted to string, > this is one-direction conversion. Yes, there are two different kinds of conversions: ones that do not change the value, and ones that change the value. It is perhaps unfortunate that they use the same syntax. I asked a question earlier, but I don't think you ever answered it. It's an important question. The question is: what kind of answer would you find satisfactory? Right now you seem to repeat the question in different ways, and none of the answers seem to get anywhere. So I feel that we need to step back and understand what kind of answer you are looking for. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Sun, Aug 28, 2016 at 12:41 AM, Dan Kortschak
wrote:
>
> This would have been a significantly shorter thread if there had been a
> clear explanation of the motivation behind slice conversion restrictions
> early. This could have been after about the second (certainly by fourth)
> post from TL where it became clear that he was asking about motivation
> rather than mechanics (the initial post was ambiguous).
I apologize for a pedantic response, but there are no slice conversion
restrictions. I agree that it's a little confusing, because
conversions are permitted among numeric types (and there are a couple
of other value-changing conversions, like between string and []byte).
As soon as you get into composite types (slices, arrays, structs,
maps, channels, functions) the rule is fairly simple: conversions are
permitted if the types have identical underlying types.
So I think the question you are asking (I honestly don't know what
question TL is asking) is: if T1 and T2 are both defined to have
identical underlying types, then why not permit conversions between
composites involving T1 and T2? Why not permit converting []T1 to
[]T2? Why not permit converting func(T1) T2 to func(T2) T1? Why not
permit converting struct { f1 T1; f2 T2 } to struct { f1 T2; f2 T1}?
In Go, types are closely tied to methods. Every type has a method
set. Another way of stating the rule for conversions between
composite types is that you can change the method set of the type
being converted (by converting to a different type, with different
methods, that has the same underlying type) but you can't change the
method set of elements of the composite.
As to why Go has that restriction, I would say that it is simply
because 1) it is conservative--people are unlikely to get into
accidental trouble; 2) real programs rarely seem to need to do this
kind of conversion.
I want to be clear here: real program do often want to do a different
kind of conversion: between interfaces with methods with different
result types, to support covariant and contravariant types. That is
not what we are talking about here. That would be difficult to
implement for reasons that have been discussed elsewhere. The
question I am addressing is why Go doesn't permit conversions between
composite types built out of non-identical types with the same
underlying type. I am asserting that that is not common in real
programs.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Sun, Aug 28, 2016 at 3:36 AM, wrote:
>
> In fact T L's experience reminds me very much of probably my first
> experience with go .. I had read the specification completely, and I thought
> 'thoroughly' - then immediately tried this :
> https://play.golang.org/p/or1Ikhr4en
>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
> var (
> x, y, z *string = new(string), new(string), new(string)
> b []*string
> )
>
> str := "please parse this"
>
> b = make([](*string), 3)
>
> fmt.Sscan(str, x, y, z)
> fmt.Sscan(str, b...) //doesn't work
> fmt.Println("x", *x, "y", *y, "z", *z)
>
> fmt.Println("b", b)
> }
>
>
> the compile error is of course "cannot use b (type []*string) as type
> []interface {} in argument to fmt.Sscan" -
>
> variadics are clear example of why allowing the suggested type conversion on
> slices of convertible types would actually be useful..
I want to make clear that I do not think this is what TL was
discussing. I think TL was asking about conversions of slices where
the element types have the same underlying type, not where the
elements types are convertible.
I completely agree that allowing type conversions between slices of
convertible types would be useful. This is not currently permitted
because it requires an implicit loop at run-time. It means that a
conversion from []T1 to []T2, although it looks like a simple change
of representation, actually requires a loop over all the elements in
the slice.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
It seems to me that this comes up often enough that it satisfies the
definition of a FAQ. I know that
https://golang.org/doc/faq#convert_slice_of_interface is commonly
pointed to as an explanation, but it is not entirely satisfactory since
it is talking about the specific case of []T to []interface{} while
commonly people want to know about []T1 to []T2 where T1 and T2 are
derived from T, so another answer is probably warranted.
On Sun, 2016-08-28 at 22:43 -0700, Ian Lance Taylor wrote:
> I want to make clear that I do not think this is what TL was
> discussing. I think TL was asking about conversions of slices where
> the element types have the same underlying type, not where the
> elements types are convertible.
>
> I completely agree that allowing type conversions between slices of
> convertible types would be useful. This is not currently permitted
> because it requires an implicit loop at run-time. It means that a
> conversion from []T1 to []T2, although it looks like a simple change
> of representation, actually requires a loop over all the elements in
> the slice.
>
> Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
Clarifying: I'm not asking a question. However, the explanation is a
good one. It could form the basis for a FAQ answer.
On Sun, 2016-08-28 at 22:40 -0700, Ian Lance Taylor wrote:
> On Sun, Aug 28, 2016 at 12:41 AM, Dan Kortschak
> wrote:
> >
> > This would have been a significantly shorter thread if there had been a
> > clear explanation of the motivation behind slice conversion restrictions
> > early. This could have been after about the second (certainly by fourth)
> > post from TL where it became clear that he was asking about motivation
> > rather than mechanics (the initial post was ambiguous).
>
> I apologize for a pedantic response, but there are no slice conversion
> restrictions. I agree that it's a little confusing, because
> conversions are permitted among numeric types (and there are a couple
> of other value-changing conversions, like between string and []byte).
> As soon as you get into composite types (slices, arrays, structs,
> maps, channels, functions) the rule is fairly simple: conversions are
> permitted if the types have identical underlying types.
>
> So I think the question you are asking (I honestly don't know what
> question TL is asking) is: if T1 and T2 are both defined to have
> identical underlying types, then why not permit conversions between
> composites involving T1 and T2? Why not permit converting []T1 to
> []T2? Why not permit converting func(T1) T2 to func(T2) T1? Why not
> permit converting struct { f1 T1; f2 T2 } to struct { f1 T2; f2 T1}?
>
> In Go, types are closely tied to methods. Every type has a method
> set. Another way of stating the rule for conversions between
> composite types is that you can change the method set of the type
> being converted (by converting to a different type, with different
> methods, that has the same underlying type) but you can't change the
> method set of elements of the composite.
>
> As to why Go has that restriction, I would say that it is simply
> because 1) it is conservative--people are unlikely to get into
> accidental trouble; 2) real programs rarely seem to need to do this
> kind of conversion.
>
> I want to be clear here: real program do often want to do a different
> kind of conversion: between interfaces with methods with different
> result types, to support covariant and contravariant types. That is
> not what we are talking about here. That would be difficult to
> implement for reasons that have been discussed elsewhere. The
> question I am addressing is why Go doesn't permit conversions between
> composite types built out of non-identical types with the same
> underlying type. I am asserting that that is not common in real
> programs.
>
> Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?
On Fri, 2016-09-02 at 13:47 -0700, nicolas riesch wrote: > In your original example, if you don't cast, it works. > > https://play.golang.org/p/g-GScYkA5S That is not doing what the OP wanted though; they wanted a []int. https://play.golang.org/p/YpyYXIu9D2 > The explanation is here: > > https://groups.google.com/forum/#!topic/golang-nuts/x3nOMDCLv5M This is a differnt thing. https://play.golang.org/p/JKgJCeXRQM -- 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.
