From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D1252DECB0; Tue, 21 Oct 2025 16:25:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761063919; cv=none; b=b676Xn2a5V33X7dhfK5XZCE0VMq6rL2CY9qiPfDebqhdG4xa++cJQcql8xBT9hlXU65RB/TY67zboZtLi+41BiQ8Cni3rbuERYb7SMfnXZSoBB/LXIGvD4Y8f+MYZElrcT72baRM3yMA3mJb65NPdFLHVSUASR55DRAAxn/4u3g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761063919; c=relaxed/simple; bh=GLITs9zjBdBSvzzK+ZY0HT3b2sXh0hAOul8PY5ytXgs=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=gtDR/b037cTZJU2LmUlQchHVXdL0OC0VLGv6Yj6OyTw9NI0IUAcKE76U7dk33LhoSChuoL3jo1J3Yks+p7TD5kxMJW2aaq57ro8RkOOEuOILXXdwEqlhYxgQ4Pe1ckgMHGE0kiMgaj+Egfx0oN86If2SH/ulhupzTUnQonsTAFE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BIpUjTDk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BIpUjTDk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69490C113D0; Tue, 21 Oct 2025 16:25:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761063919; bh=GLITs9zjBdBSvzzK+ZY0HT3b2sXh0hAOul8PY5ytXgs=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=BIpUjTDkqAI6vPrOLhNtZyWgzjiiBCif8978z7YcatrcV2X0hUk5Be/b66Be3dQhE D0lDE2f1v0HR/eFqOlFOrMIiMj1vFaiNfY9zngnT706UdrNlLK5kqWRxv75NTmPLl3 QtKFOOdi0b9JLMl9jJJdtPhZisVzNdrUOcAVKckXX6gl66KUSHMl4mfAwgBVGkgKKA jFxogmhPnHq7V91cWMoWdagGpiDJf36eddEntQV+IfYriqCH/BPW8Wfin4Wi8fyymp EeYKIgh0e4JXZB0WUvcFwaxPX9Kya5N8f1nMqTr8WAh9JUteeGlWhTOtqUSBse4gO/ uLiQgZDcraQdw== Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 21 Oct 2025 18:25:13 +0200 Message-Id: Subject: Re: [PATCH v2 1/8] rust: fs: add file::Offset type alias Cc: , , , , , , , , , , , , , , , "Alexander Viro" , "Christian Brauner" , "Jan Kara" To: "Miguel Ojeda" From: "Danilo Krummrich" References: <20251020222722.240473-1-dakr@kernel.org> <20251020222722.240473-2-dakr@kernel.org> In-Reply-To: On Tue Oct 21, 2025 at 6:00 PM CEST, Miguel Ojeda wrote: > On Tue, Oct 21, 2025 at 5:26=E2=80=AFPM Danilo Krummrich wrote: >> >> Yeah, I don't think there's any value making this a new type in this cas= e. There >> are no type invariants, useful methods, etc. >> >> In fact, not even the type alias is strictly needed, as i64 would be suf= ficient >> as well. > > Even if there are no type invariants nor methods, newtypes are still > useful to prevent bad operations/assignments/... > > In general, it would be ideal to have more newtypes (and of course > avoid primitives for everything), but they come with source code > overhead, so I was wondering here, because it is usually one chance we > have to try to go with something stronger vs. the usual C way. We need arithmetic operations (e.g. checked_add()) and type conversions (e.= g. from/into usize). That'd be quite some code to write that just forwards to = the inner primitive. So, I think as by now a new type makes sense if there is some reasonable additional semantics to capture. Of course, if we'd have modular derive mac= ros I think it is reasonable and makes sense to also do it in cases like this one= . Maybe the action to take from this is to add this to the list of (good firs= t) issues (not sure this is actually a _good first_ issue though :).