What worries me is code like this:
func f() any {
int *i
return i
}
func main() {
if f()==nil {
...
}
}
Use of "any" makes it look like f returns an *int and f() is nil, but
it is not, because "any" is interface{}.
I think "any" as a constraint is useful, like "comparable", but "any"
as a type is misleading.
Isn't your example just a case of confusing a nil interface with a nil value inside a generic interface? How does requiring writing it as `func f() interface{} {` make the behavior any clearer?
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/10264F88-82EB-4E01-AF28-E2057C08571E%40iitbombay.org.
interface{}, when used as a constraint, doesn't mean than the value
has to be an interface{}, it means the value can be anything.
interface{}, when used as a value, doesn't mean that the value can be
anything, it means that the value is an interface, and you have to get
the value from that interface. Different uses, different identifiers.
Just to clarify, the intent is to make the declaration in the spec `type any = interface{}`, not `type any interface{}`, correct? The latter would be more analogous to `error`. Either has certain advantages and disadvantages, I'm not sure which I prefer, but I just want to make sure I understand the plan :)
2.
We’re going to simplify the rule for type list satisfaction. The type
argument will satisfy the constraint if the type argument is identical
to any type in the type list, or if the underlying type of the type
argument is identical to any type in the type list. What we are
removing here is any use of the underlying types of the types in the
type list. This tweaked rule means that the type list can decide
whether to accept an exact defined type, other than a predeclared
type, or whether to accept any type with a matching underlying type.
This is a subtle change that we don’t expect to affect any existing
experimental code.
We think that this definition might work if we permit interface types
with type lists to be used outside of type constraints. Such
interfaces would effectively act like sum types. That is not part of
this design draft, but it’s an obvious thing to consider for the
future.
Note that a type list can mention type parameters (that is, other type
parameters in the same type parameter list). These will be checked by
first replacing the type parameter(s) with the corresponding type
argument(s), and then using the rule described above.
3.
We’re going to clarify that when considering the operations permitted
for a value whose type is a type parameter, we will ignore the methods
of any types in the type list. The general rule is that the generic
function can use any operation permitted by every type in the type
list. However, this will only apply to operators and predeclared
functions (such as "len" and "cap"). It won’t apply to methods, for
the case where the type list includes a list of types that all define
some method. Any methods must be listed separately in the interface
type, not inherited from the type list.
This rule seems generally clear, and avoids some complex reasoning
involving type lists that include structs with embedded type
parameters.
4.
We’re going to permit type switches on type parameters that have type
lists, without the “.(type)” syntax. The “(.type)” syntax exists to
clarify code like “switch v := x.(type)”. A type switch on a type
parameter won’t be able to use the “:=” syntax anyhow, so there is no
reason to require “.(type)”. In a type switch on a type parameter
with a type list, every case listed must be a type that appears in the
type list (“default” is also permitted, of course). A case will be
chosen if it is the type matched by the type argument, although as
discussed above it may not be the exact type argument: it may be the
underlying type of the type argument. To make that rule very clear,
type switches will not be permitted for type parameters that do not
have type lists. It is already possible to switch on a value “x”
whose type is a type parameter without a type list by writing code
like “switch (interface{})(x).(type)” (which may now be written as
“switch any(x).(type)”). That construct is not the simplest, but it
uses only features already present in the language, and we don’t
expect it to be widely needed.
All constraints except "any" specify a constraint for the type. A
Stringer constraint will ensure that the type has String() string
method. "any" is a lack of constraint.
My problem is the attractiveness of "any" as a return type.
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUFU_Lz0c%3D-6V6N9X2Ku2Hx-9%2BDeHequ0oLX9Soyo_3GQ%40mail.gmail.com.
People don't use the empty interface because they like it so much, but because Go doesn't have parametric polymorphism / "generics" yet.
My one concern with making it an alias is error messages.If the source code says "any", I think so should the error messages. Currently, the compiler forgets aliases too early.
My one concern with making it an alias is error messages.If the source code says "any", I think so should the error messages. Currently, the compiler forgets aliases too early.
We’re going to simplify the rule for type list satisfaction. The type
I'd assume that would fail to compile as you're returning a []T not a []int
On Fri, 21 Aug 2020 at 22:10, jimmy frasche <soapbo...@gmail.com> wrote:I'd assume that would fail to compile as you're returning a []T not a []intIf that's the case, then I'm not sure that such a type switch would be very useful. It would tell you what type the values are, but you can't do anything with them because all the values would still be of the original type.
I had assumed that the intention was that within the arm of the type switch, the switched type would take on the specified type.That would allow (for example) specialising to use underlying machine operations on []T when T is a known type such as byte.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJhgacjTm%3DC-6f%2B4%2BA0HCTDT0_U7pQZOmRjShuzigdocDzAcww%40mail.gmail.com.