jimmyfrasche

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

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

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

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

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

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)?

jimmyfrasche

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

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

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

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