91–100 of 223 posts
Earlier quoted context omitted.
unfortunately replace is not supported well with modules. and they are hell bent on not supporting it well.
I've been doing forks of modules and using replace to use them in my code base extensively. I had 0 problems, it works marvelously. If you're doing some kind of global find/replace on fork, then something's definitely not right.
Earlier quoted context omitted.
Depending on code review instead of a static type system does not scale. Look at all of the memory safety security vulnerabilities that are solved by "simply making sure to manage memory correctly." Also: variableDefinedInAFarAwayModule := 17 ... TestSomething(variableDefinedInAFarAwayModule) It's not always as clear as a constant value being passed to an incorrect type.
I don't understand your example here, that's not going to compile. variableDefinedInAFarAwayModule is definitionally type int and will not be cast. It is also unpublished, so you couldn't be using it for a faraway module? Your 17 in the previous example has it's typed determined at compile time which is why it can be a problem. see: https://go.dev/play/p/jEdAhKDeLy6
Earlier quoted context omitted.
No need to invent a new keyword, it is ok to just use "const": https://github.com/go101/go101/wiki/An-immutable-value-propo...
No, they are very different conceptually. - A const is an abstracted value. - A variable is an allocated piece of memory.
I have much smaller ask struct type elision in function calls
I have to say I’ve no idea what you mean. In function definitions I’d interpret it as type inference (and would disagree) but you specifically talk about function calls , and consider it a small change. Can you describe what you’re thinking of?
Currently, you would have to invoke it like so:
svc.GetObjectWithContext(ctx, &s3.GetObjectInput{Bucket: bucket, Key: key})
svc.GetObjectWithContext(ctx, &{Bucket: bucket, Key: key})
[]someStruct{{Field: value}, {Field: value}}
[]someStruct{someStruct{Field: value}, someStruct{Field: value}}
[0]: https://docs.aws.amazon.com/sdk-for-go/api/service/s3/#S3.Ge...
Earlier quoted context omitted.
> Use int-type enums with iota: […] no compile-time guard against illegal enum values Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package. See: https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...
This compiles: type Test int const ( T1 Test = 0 T2 = 1 ) func TestSomething(t Test) {} ... TestSomething(17) So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.
package main
import "fmt"
type Test int
const (
T1 Test = 0
T2 = 1
)
func main() {
t, err := TestString("T1")
if err != nil {
panic(err)
}
TestSomething(t)
}
func TestSomething(t Test) {
fmt.Println(t.String())
}
Earlier quoted context omitted.
No, they are very different conceptually. - A const is an abstracted value. - A variable is an allocated piece of memory.
Concepts are defined as needed.
- as of right now they are different, and clearly distinct, and it's actually important to unlearn thinking of a const as a var, because they don't do the same thing in practical terms
- that proposal would muddy the distinction.
Earlier quoted context omitted.
> Use int-type enums with iota: […] no compile-time guard against illegal enum values Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package. See: https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...
This compiles: type Test int const ( T1 Test = 0 T2 = 1 ) func TestSomething(t Test) {} ... TestSomething(17) So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.
TestSomething(T1 & T2)Earlier quoted context omitted.
> but (deterministic-select cases) hey are peculiar. It looks for most select blocks in Go code, it doesn't matter whether or not they are non-deterministic or deterministic. But, if the default is deterministic, user code could simulate non-deterministic, without much performance loss. Not vice versa (the current design).
Any time there is more than one channel being selected for it needs to cover them all equally.
In fact, in practice, sometimes, I do hope one specified case has a higher priority than others if they are all non-blocking.
Earlier quoted context omitted.
Concepts are defined as needed.
That wasn't exactly what I meant. What I meant was - as of right now they are different, and clearly distinct, and it's actually important to unlearn thinking of a const as a var, because they don't do the same thing in practical terms - that proposal would muddy the distinction.
I mean we could let some const values allocated in memory.
Earlier quoted context omitted.
This compiles: type Test int const ( T1 Test = 0 T2 = 1 ) func TestSomething(t Test) {} ... TestSomething(17) So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.
I generally tend to use enumer[0] to generate some boilerplate code that can help with addressing this, e.g. the below would compile, but would error at runtime. There are probably linters out there that could catch this. With Go, linters are generally pretty good at catching this kind of stuff. package main import "fmt" type Test int const ( T1 Test = 0 T2 = 1 ) func main() { t, err := TestString("T1") if err != nil…
Like C or C++ do? :)