[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r0uimutn.ffs@tglx>
Date: Wed, 22 Feb 2023 01:01:56 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Heghedus Razvan <heghedus.razvan@...tonmail.com>
Cc: Asahi Lina <lina@...hilina.net>, Boqun Feng <boqun.feng@...il.com>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
John Stultz <jstultz@...gle.com>,
Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org, asahi@...ts.linux.dev
Subject: Re: [PATCH] rust: time: New module for timekeeping functions
On Tue, Feb 21 2023 at 21:33, Heghedus Razvan wrote:
> On Tuesday, February 21st, 2023 at 8:45 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>> That's the same the Rust std time semantics:
>>
>> Duration = Instance - Instance valid
>> Duration = Systemtime - SystemTime valid
>> Duration = Systemtime - Instance invalid
>>
>> No?
>>
> I agree with Thomas on this one. The Rust type system is really
> powerful and we should take advantage of it. Time deltas can be
> enforced to be from the same clock at compile time. Just for the sake
> of it, I wrote a small example on how this can be achieve:
> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1d0f70bb5329b181f203ce7270e2957a
Cute. This code makes even sense to Rustagnostics like me.
Thanks,
tglx
Powered by blists - more mailing lists