From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: proposal to make null string handling more emacs-y Date: Thu, 26 Apr 2012 21:10:57 -0400 Message-ID: References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1335489071 2706 80.91.229.3 (27 Apr 2012 01:11:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Apr 2012 01:11:11 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Steve Yegge Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 27 03:11:10 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SNZiF-0003B6-V8 for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 03:11:08 +0200 Original-Received: from localhost ([::1]:55628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNZiF-0003mH-4N for ged-emacs-devel@m.gmane.org; Thu, 26 Apr 2012 21:11:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNZiC-0003m0-78 for emacs-devel@gnu.org; Thu, 26 Apr 2012 21:11:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNZiA-000722-Mg for emacs-devel@gnu.org; Thu, 26 Apr 2012 21:11:03 -0400 Original-Received: from ironport-out.teksavvy.com ([206.248.143.162]:53755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNZi8-00071m-2O; Thu, 26 Apr 2012 21:11:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYIACxOgk/O+LN8/2dsb2JhbABDuCMDgQyBCIIJAQEEAVYjBQsLNBIUGA0kiBwFtjKLYYR5BKRFgV2DAw X-IronPort-AV: E=Sophos;i="4.75,391,1330923600"; d="scan'208";a="176973018" Original-Received: from 206-248-179-124.dsl.teksavvy.com (HELO pastel.home) ([206.248.179.124]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 26 Apr 2012 21:10:58 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E975359005; Thu, 26 Apr 2012 21:10:57 -0400 (EDT) In-Reply-To: (Steve Yegge's message of "Thu, 26 Apr 2012 14:20:45 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.143.162 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150073 Archived-At: > There's a lot of code out there that's forced to do type assertions on > string args that could be simplified if these common functions could > accept nils. I can believe that (it's often handy to use "nil-in-nil-out" when composing functions which may return nil). But there's also the risk that you hide real errors, leading to weird behaviors that are more difficult to track down. E.g. one package uses some other package's var before it's initialized, so with the current semantics you might get a clean error, whereas with your proposed semantics you might get some weird behavior where the user says why doesn't bar find my thingy even though C-h v foo-var tells me it's set to "/some/path"? -- Stefan