From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Introducing 'safety' compilation parameter Date: Tue, 07 May 2024 12:13:36 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40012"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, Eli Zaretskii , mattias.engdegard@gmail.com, stefankangas@gmail.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 07 18:14:09 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s4NSC-000AA8-ST for ged-emacs-devel@m.gmane-mx.org; Tue, 07 May 2024 18:14:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4NRs-0005Tp-02; Tue, 07 May 2024 12:13:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4NRp-0005Sq-JA for emacs-devel@gnu.org; Tue, 07 May 2024 12:13:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4NRo-0007Sg-V9; Tue, 07 May 2024 12:13:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=skpbg/d7bGMVoIw0ZiDG8bhJNPc0k4dUZOx2UZE2Pp0=; b=OjPCL56W3DfvjjoPSN4F E3Cyt6hAfk9QRSqTfzKMRJt2NT+doYFhEY1JHkGOWxc+O1nQV0GeSCLdPjA84H7yePVLXNPOUowyZ L0TF672pxBs5K5DUqzexEisBxqTZaelFGcUIbJrT+PF1St4+qVnZhcrcLuEncI2WG9ncNmWy5waFW XIPK4CfXUSmQyrr05WW4jpIaZhx+B+xl1z8OI0Qcen9vHcVvMdiT5B03ScPhs4NF0AP/qO9KUGZtf eS9lLd/CS+CJOyGOhqu1IWLPu6LfoBnqPAv7YVYhVflu+7O3cdMb7CNCsKf+3kMUynplrIBncMhY2 svw5nGpjSAy81Q==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s4NRg-0003T1-Ip; Tue, 07 May 2024 12:13:37 -0400 In-Reply-To: (Stefan Monnier's message of "Tue, 07 May 2024 10:56:36 -0400") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318955 Archived-At: Stefan Monnier writes: >> I didn't want to give safety a prefix (byte- or comp-) as I believe we >> should extend safety in the future with a value to have the byte >> compiler generates runtime type checks to verify the declred types. > > I don't see a strong need for a namespace prefix, but I think "safety" > is too general a term. It could be understood to apply also to > unrelated circumstances such as process confinement or disclosure of > sensitive info over a network connection. > Maybe `elisp-safety` or `compilation-safety`? Agree, boths SGTM, maaaybe I slightly prefer 'compilation-safety'. > If I read your patch correctly, we get safety in a roundabout way: > rather than test the safety setting at the spot where we decide to apply > (or not) a dangerous optimization, we use the safety setting to > "mollify" the type annotations (presumably because this will in turn > make the risky optimizations inapplicable). > > What is the reason for that? No specific reason, I think I thought was safer to write the patch with way gating optimization at this (higher) level. Thinking about now that you raised the point, is probably easy to gate the single optimizations as well. Why not, I think I'll update the patch this way. Thanks Andrea