Skip to content

Instantly share code, notes, and snippets.

github.com/caddyserver/caddy/v2:
keyed struct literals: 54
total KV pairs: 116
non-candidate KV pairs: 59
ident:
total: 33
no match: 22
exact: 1
partial: 10
qual.ident:
@jimmyfrasche
jimmyfrasche / inspect.go
Created February 28, 2019 22:08
stdlib error handling
// Copyright 2019 jimmyfrasche
//
// Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
//
// 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
//
// 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROF
@jimmyfrasche
jimmyfrasche / feedback.md
Created September 6, 2018 16:36
error handling feedback

My concern with the check/handle mechanism is that it makes the error interface and the zero value special.

This can be avoided at the cost of an increase in implementation complexity and slightly less decrease in boilerplate. Perhaps it's better to avoid the complexity, but this is what it would look like if it were generalized:

handle requires a type and a conditional. It looks more like an if statement:

handle err error; err != nil {
  // ...
}
@jimmyfrasche
jimmyfrasche / proposal.md
Created September 4, 2018 02:15
generics proposal

Note

This proposal relies on other proposals:

  • golang/go#8082 - consider two defined interfaces with identical definition to be identical
  • golang/go#19642 - define a universal, untyped zero value; written as zero in this proposal, pending choice of a syntax.
  • golang/go#26842 - allow all incomparable types to be compared against zero
  • golang/go#27481 allow interfaces to specify that they are only satisfied by comparable types. This document uses the variant that achieves this by using or embedding the predeclared comparable interface.

Abstract

@jimmyfrasche
jimmyfrasche / gist:04ca2146c9130dab4d993365313722fb
Last active September 12, 2018 17:29
Error Inspection feedback

These operations would help but they're not unique to errors, even though they most often arise in that context.

Since this proposal relies on some form of generics to implement As, why not make the interface and both operations generic so we can Is or As a wrapped io.Reader just as easily?

@jimmyfrasche
jimmyfrasche / gist:e02fcbefee5cb14228768afec17abbee
Last active August 29, 2018 20:17
Error Printing feedback

LGTM, but I don't see why these interfaces are or should be limited to errors.

Much of this would have to be implemented in fmt so why not define the interfaces there (with appropriate renaming like BasicFormatter or what have you)?

cmd/cgo:gcc.go:2527
cmd/cgo:main.go:307
cmd/doc:main.go:314
cmd/go_test:go_test.go:1006
cmd/go_test:go_test.go:1777
cmd/go_test:go_test.go:1795
cmd/go_test:go_test.go:1806
cmd/go_test:go_test.go:1913
cmd/go_test:go_test.go:1926
cmd/go_test:go_test.go:1939
@jimmyfrasche
jimmyfrasche / sum-default.md
Created August 24, 2017 18:58
Issues with default when simulating sum types

I think exhaustiveness has been a red herring in the sum type discussion.

It's looking at the problem from the wrong direction.

The important issue is not to ensure that every defined case is checked. Rather, it is to ensure that only the defined cases are possible.

Let's consider a non-exhaustive example.

Say we have a sum type, S, that can only take the types A, B, C, D, or E. We want to define a function, F, that does something if the type is A, B, or C and otherwise does nothing at all.

@jimmyfrasche
jimmyfrasche / combine.go
Last active August 22, 2017 00:07
sketch of optimizing value-combiner
package reflectutil
import (
"reflect"
"strconv"
"strings"
)
//Combine(s, t), where s is of type S and t is of type T, returns a combined value
//with a type roughly equivalent to
@jimmyfrasche
jimmyfrasche / xr.md
Created August 18, 2017 01:31
Sum types experience report

Interfaces only allow you to model based on method set and they are, by design, open. Any type that satisfies the interface, satisfies the interface. They share some similarities to sum types, but, as far as they do, they are, essentially, infinite sums. While this often desired, there are times when you need to limit the options to a closed set of types.

There's no direct way in Go to say "these types, even though they share no methods in common". You have to use an interface{}, which says nothing—even though you know exactly what you want to say. You have to handle an invalid case at runtime.

There's no direct way to specify only the types in this package. Using an interface with an unexported "tag" method gets you part of the way. There's still nil and embedding and, at every point, those need to be dealt with—or, all too often, ignored.

These cases can lead to trivial errors that could be caught by the compiler, but instead need to be handled by defensive coding and extensive testing. Defensive codin