core.match

throw on unsuccessful match

Details

  • Type: Defect Defect
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

I was on the fence about this. But after looking at the literature as well as the behavior of condp, I've decided that throwing on unsuccessful match is the way to go. This is particularly important since we put no constraints on the types allowed - we cannot determine exhaustiveness.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Pollak added a comment -

FWIW, I think the existing behavior (returning a nil) is the correct behavior. If a user wants to throw an exception, they can add an :else clause.

Why is the existing behavior correct?

Think of a Map as a match. When you look up a key that is not in the Map, you get a nil. There are simple ways to add additional behavior to maps to return something other than a nil, but the default is nil.

A Map, like a pattern match, is defined at some values of the input and not other values of the input.

Show
David Pollak added a comment - FWIW, I think the existing behavior (returning a nil) is the correct behavior. If a user wants to throw an exception, they can add an :else clause. Why is the existing behavior correct? Think of a Map as a match. When you look up a key that is not in the Map, you get a nil. There are simple ways to add additional behavior to maps to return something other than a nil, but the default is nil. A Map, like a pattern match, is defined at some values of the input and not other values of the input.
Hide
Permalink
David Nolen added a comment - - edited

The behavior aligns with Clojure's case. The issue is that Clojure being dynamically typed (and match actively taking advantage of this) can't really do exhaustiveness checking in all cases - I think throwing is desirable, and experience seems to suggest this as well - otherwise nils will flow in likely unintentional ways. Users can always add the explicit nil return if they like. I suspect users will not do this.

Show
David Nolen added a comment - - edited The behavior aligns with Clojure's case. The issue is that Clojure being dynamically typed (and match actively taking advantage of this) can't really do exhaustiveness checking in all cases - I think throwing is desirable, and experience seems to suggest this as well - otherwise nils will flow in likely unintentional ways. Users can always add the explicit nil return if they like. I suspect users will not do this.

People

Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4#649-r158309) | Report a problem
Powered by a free Atlassian JIRA open source license for Clojure. Try JIRA - bug tracking software for your team.