From ajieskola at gmail.com Fri Oct 4 09:44:33 2024 From: ajieskola at gmail.com (Dukc) Date: Fri, 04 Oct 2024 09:44:33 +0000 Subject: Safer D first draft In-Reply-To: References: Message-ID: On Tuesday, 24 September 2024 at 19:23:57 UTC, Quirin Schroll wrote: > > Maybe `Expression.ptr` can be `@safe` if the compiler can > statically prove that `Expression` has non-zero length or is a > string literal (which is always zero-terminated). I don't think that's a good idea. First off, it makes it implementation-defined if a particular piece of code complies. When you have `someString.ptr`, It might be that compiler A figures out `someString` is never `""`, but compiler B doesn't. Therefore, A will accept it in a `@safe` function, B won't. Worse, if the function has attribute auto-inference, A and B will infer different attributes for the function, leading to confusing breakage when switching compilers. Second, you can work around this by writing `&Expression[0]`. If the compiler could figure out that `Expression.ptr` would be safe, it can just as well figure out that bounds checks for `&Expression[0]` aren't needed. From ajieskola at gmail.com Fri Oct 4 09:50:58 2024 From: ajieskola at gmail.com (Dukc) Date: Fri, 04 Oct 2024 09:50:58 +0000 Subject: Safer D first draft In-Reply-To: References: Message-ID: On Friday, 4 October 2024 at 09:44:33 UTC, Dukc wrote: > It might be that compiler A figures out `someString` is never > `""` Actually `""` would be safe if string literals are zero-terminated as in DMD. Should probably have written `new string(0)` or something. From ajieskola at gmail.com Fri Oct 4 10:34:21 2024 From: ajieskola at gmail.com (Dukc) Date: Fri, 04 Oct 2024 10:34:21 +0000 Subject: Safer D first draft In-Reply-To: References: Message-ID: On Monday, 23 September 2024 at 09:02:28 UTC, Walter Bright wrote: > https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md The idea that `@trusted` functions will get the same checks as default functions is not a good idea. Take a member function of a custom array, for instance: ```D // Currently: @trusted pure nothrow @nogc opIndex(size_t index) { if(index >= length) assert(0); return ptr[index]; } // With this DIP, it has to be: @trusted pure nothrow @nogc opIndex(size_t index) { if(index >= length) assert(0); return (() @system => ptr[index])(); } ``` It's going to be a LOT of work to convert all `@trusted` functions to be like this. You could argue it helps the reviewer, as the system code is highlighted by these `@system` lambdas. Alas, this would be of minimal use. Spotting language-defined unsafe operations, like pointer arithmetic and casts of unsafe values, is relatively easy. What is harder is spotting calls to `@system` functions, since those are different for each codebase and can't be memoized unlike language rules. The proposed rule would help with the easy part but not the hard one. So please, leave rules for `@trusted` functions as they are now. In the "Prior work", mention OpenD. It already has a kind of "safer by default" which is actually (not far off from what this DIP suggests)[https://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_03_25.html]. Overall... well I'm not sure. Sure, this DIP would improve safety over the present status quo, assuming `@trusted` rules aren't changed. But since we have editions, can't we just do a real `@safe` by default? We could make `@safe` external C functions forbidden - they would have to be `@system` or `@trusted`. That would avoid the question whether external C functions should be exempt from the change. From ajieskola at gmail.com Fri Oct 4 11:13:19 2024 From: ajieskola at gmail.com (Dukc) Date: Fri, 04 Oct 2024 11:13:19 +0000 Subject: Fourth Draft: Primary Type Syntax In-Reply-To: References: Message-ID: On Tuesday, 24 September 2024 at 20:50:58 UTC, Quirin Schroll wrote: > The obligatory > [permalink](https://github.com/Bolpat/DIPs/blob/fcb076e4be19abf634bcadbb7567c49ed80c084c/DIPs/DIP-2NNN-QFS.md) and [latest draft](https://github.com/Bolpat/DIPs/blob/PrimaryTypeSyntax/DIPs/DIP-2NNN-QFS.md). > > The only difference is new subsections of [??Maximal Munch > Exceptions](https://github.com/Bolpat/DIPs/blob/fcb076e4be19abf634bcadbb7567c49ed80c084c/DIPs/DIP-2NNN-QFS.md#maximal-munch-exceptions). A question, probably out of ignorance: Why do function pointers / delegates need to care about their linkage type? I thought that a function pointer can freely point to any function that is otherwise of the correct type, regardless of it's linkage type. Is this not the case? From richard at cattermole.co.nz Fri Oct 4 22:24:15 2024 From: richard at cattermole.co.nz (Richard (Rikki) Andrew Cattermole) Date: Sat, 5 Oct 2024 11:24:15 +1300 Subject: Fourth Draft: Primary Type Syntax In-Reply-To: References: Message-ID: On 05/10/2024 12:13 AM, Dukc wrote: > On Tuesday, 24 September 2024 at 20:50:58 UTC, Quirin Schroll wrote: >> The obligatory >> [permalink](https://github.com/Bolpat/DIPs/blob/fcb076e4be19abf634bcadbb7567c49ed80c084c/DIPs/DIP-2NNN-QFS.md) and [latest draft](https://github.com/Bolpat/DIPs/blob/PrimaryTypeSyntax/DIPs/DIP-2NNN-QFS.md). >> >> The only difference is new subsections of [??Maximal Munch >> Exceptions](https://github.com/Bolpat/DIPs/blob/fcb076e4be19abf634bcadbb7567c49ed80c084c/DIPs/DIP-2NNN-QFS.md#maximal-munch-exceptions). > > A question, probably out of ignorance: Why do function pointers / > delegates need to care about their linkage type? > > I thought that a function pointer can freely point to any function that > is otherwise of the correct type, regardless of it's linkage type. Is > this not the case? No. Linkage affects both mangling and the ABI (how it is called). Parameters and return values could be in different locations if it was mixed up. From ajieskola at gmail.com Mon Oct 7 17:53:52 2024 From: ajieskola at gmail.com (Dukc) Date: Mon, 07 Oct 2024 17:53:52 +0000 Subject: Fourth Draft: Primary Type Syntax In-Reply-To: References: Message-ID: On Friday, 4 October 2024 at 22:24:15 UTC, Richard (Rikki) Andrew Cattermole wrote: > No. > > Linkage affects both mangling and the ABI (how it is called). > > Parameters and return values could be in different locations if > it was mixed up. I see, thanks. In that case it's good that the DIP addresses it. In general I like a lot about this DIP is proposing but I should do a deeper dive. Maybe I will but not today. From crazymonkyyy at gmail.com Tue Oct 15 14:37:24 2024 From: crazymonkyyy at gmail.com (monkyyy) Date: Tue, 15 Oct 2024 14:37:24 +0000 Subject: Statement Unittest [DRAFT] Message-ID: A module-level unittest statement( uses `()` instead of `{}`) for single asserts , with an optional string message ```d unittest(1==1); unittest(1==1,"math broke"); ``` https://gist.github.com/crazymonkyyy/2afa7ae1402cd246fb98bdb86dd19605 From snarwin at gmail.com Tue Oct 15 15:56:42 2024 From: snarwin at gmail.com (Paul Backus) Date: Tue, 15 Oct 2024 15:56:42 +0000 Subject: Statement Unittest [DRAFT] In-Reply-To: References: Message-ID: On Tuesday, 15 October 2024 at 14:37:24 UTC, monkyyy wrote: > https://gist.github.com/crazymonkyyy/2afa7ae1402cd246fb98bdb86dd19605 For "Prior Work", I'd say the most obvious thing to cite is the shortened syntax for `in`, `out`, and `invariant` contracts: ```d // Short versions in (n > 0); out (ret; ret !is null); invariant (start <= end); // Long versions in { assert(n > 0); } out (ret) { assert(ret !is null); } invariant { assert( start <= end); } ``` Spec links: * [Function contracts][1] * [Struct invariants][2] * [Class invariants][3] [1]: https://dlang.org/spec/function.html#contracts [2]: https://dlang.org/spec/struct.html#Invariant [3]: https://dlang.org/spec/class.html#invariants From guillaume.piolat at gmail.com Thu Oct 17 23:48:35 2024 From: guillaume.piolat at gmail.com (Guillaume Piolat) Date: Thu, 17 Oct 2024 23:48:35 +0000 Subject: Statement Unittest [DRAFT] In-Reply-To: References: Message-ID: On Tuesday, 15 October 2024 at 14:37:24 UTC, monkyyy wrote: > A module-level unittest statement( uses `()` instead of `{}`) > for single asserts > , with an optional string message > > ```d > unittest(1==1); > unittest(1==1,"math broke"); > ``` > > > https://gist.github.com/crazymonkyyy/2afa7ae1402cd246fb98bdb86dd19605 This is a pretty cool idea. unittest being one of the big win of D, why not have more of it. From ajieskola at gmail.com Sat Oct 19 07:03:05 2024 From: ajieskola at gmail.com (Dukc) Date: Sat, 19 Oct 2024 07:03:05 +0000 Subject: Fourth Draft: Primary Type Syntax In-Reply-To: References: Message-ID: Time for another dive. I still generally like this proposal. But I did gather a few issues. > However, unless misleading spaces are inserted between the type > qualifier and the opening parenthesis, this exception follows > mathematical conventions and programmers? intuition This left me confused for quite a while. The exception to parsing rules that the present language has, or exception relative to current meaning the suggested changes could lead to? I did figure out you meant that the meaning of `const(int)[]` will NOT change, but it took me some time to insure myself of that. > linkage In declarations, linkage works mostly like attributes (both user-defined and language-defined) do. Would it be better for them to be declared like attributes are for function pointers and delegates: after the parameter list? In other words, `extern` qualifiers would become part of `FunctionAttribute` in the grammar. Of course, this should be allowed for all function declarations, not just function pointers/delegates. There's one potential weakness in my idea though: it assumes that non-function pointers don't and won't care about the linkage of the pointee. Should we assume this is the case? I don't know. Regardless, probably `ref` is best left at the beginning like proposed though. Were `ref` allowed at end of the attribute list, the meaning of `scope ref` or `return ref` in a member function would be really confusing: does it make the `this` reference (that the `scope`/`return` applies to) `ref` or the return type? > anonymous classes Example? I maybe know what you're writing about and proposing here but it's hard to be sure. ------- Maybe while there, you could also propose a syntax for function types without needing `alias` declarations for that? It doesn't have to be particulary pretty since we're usually not supposed to use them, but I still think they should be grammatically valid. From newshound2 at digitalmars.com Thu Oct 31 06:23:24 2024 From: newshound2 at digitalmars.com (Walter Bright) Date: Wed, 30 Oct 2024 23:23:24 -0700 Subject: First Draft: Placement New Expression Message-ID: Based on a suggestion by Manu Evans: https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md From richard at cattermole.co.nz Thu Oct 31 06:33:05 2024 From: richard at cattermole.co.nz (Richard (Rikki) Andrew Cattermole) Date: Thu, 31 Oct 2024 19:33:05 +1300 Subject: First Draft: Placement New Expression In-Reply-To: References: Message-ID: I recommend that this includes allocator support. ```d struct Allocator { void[] allocate(size_t, TypeInfo ti=null); void deallocate(void[]); } ``` We would need a way to tie into deallocate + destroy. Say perhaps ``delete(allocator) thing;`` statement? This little bit of convenience would be a huge QoL improvement, as it'll calculate the size needed to be allocated for you (including for say arrays). This can be a bit of paid to do properly due to overflow. > The size of the memory object of class Type can be retrieved with the expression __traits(initSymbol, Type).length. ```d pragma(msg, __traits(initSymbol, Foo).length); struct Foo { int x; } ``` ``` onlineapp.d(1): Error: cannot determine the address of the initializer symbol during CTFE onlineapp.d(1): while evaluating `pragma(msg, Foo.length)` ``` We need a CTFE'able solution to this, for that argument to hold. From richard at cattermole.co.nz Thu Oct 31 06:33:51 2024 From: richard at cattermole.co.nz (Richard (Rikki) Andrew Cattermole) Date: Thu, 31 Oct 2024 19:33:51 +1300 Subject: First Draft: Placement New Expression In-Reply-To: References: Message-ID: On 31/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote: > This little bit of convenience would be a huge QoL improvement, as it'll > calculate the size needed to be allocated for you (including for say > arrays). This can be a bit of paid to do properly due to overflow. Ugh s/paid/pain/ From ryuukk.dev at gmail.com Thu Oct 31 11:18:22 2024 From: ryuukk.dev at gmail.com (ryuukk_) Date: Thu, 31 Oct 2024 11:18:22 +0000 Subject: First Draft: Placement New Expression In-Reply-To: References: Message-ID: On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote: > Based on a suggestion by Manu Evans: > > https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md > If one desires to use classes without the GC, such as in > BetterC, it's just awkward to use emplace. Walter, you made -betterC, you are supposed to know there is no such thing as "TypeInfo", therefore no such thing as "class", it ain't -betterJava++ is it? From john.michael.hall at gmail.com Thu Oct 31 12:30:41 2024 From: john.michael.hall at gmail.com (jmh530) Date: Thu, 31 Oct 2024 12:30:41 +0000 Subject: First Draft: Placement New Expression In-Reply-To: References: Message-ID: On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote: > Based on a suggestion by Manu Evans: > > https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md Can you add an example? From nick at geany.org Thu Oct 31 18:17:56 2024 From: nick at geany.org (Nick Treleaven) Date: Thu, 31 Oct 2024 18:17:56 +0000 Subject: First Draft: Placement New Expression In-Reply-To: References: Message-ID: On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote: > Based on a suggestion by Manu Evans: > > https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md > With the placement new expression, operator new can initialize > an object into any location. It replaces the functionality of > core.lifetime.emplace. It would be good if any DIP that replaces `emplace` could avoid violation of immutable data in @system code, or at least in @safe: https://issues.dlang.org/show_bug.cgi?id=24795 From snarwin at gmail.com Thu Oct 31 18:19:04 2024 From: snarwin at gmail.com (Paul Backus) Date: Thu, 31 Oct 2024 18:19:04 +0000 Subject: First Draft: Placement New Expression In-Reply-To: References: Message-ID: On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote: > Based on a suggestion by Manu Evans: > > https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md Sounds great. No notes. ? From snarwin at gmail.com Thu Oct 31 18:21:13 2024 From: snarwin at gmail.com (Paul Backus) Date: Thu, 31 Oct 2024 18:21:13 +0000 Subject: First Draft: Placement New Expression In-Reply-To: References: Message-ID: On Thursday, 31 October 2024 at 18:17:56 UTC, Nick Treleaven wrote: > On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright > wrote: >> Based on a suggestion by Manu Evans: >> >> https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md > >> With the placement new expression, operator new can initialize >> an object into any location. It replaces the functionality of >> core.lifetime.emplace. > > It would be good if any DIP that replaces `emplace` could avoid > violation of immutable data in @system code, or at least in > @safe: > https://issues.dlang.org/show_bug.cgi?id=24795 Easiest way to do this is to allow using a `void[]` for all types, not just classes.