digitalmars.D - What features of D you would not miss?
- Dukc (16/62) Sep 15 2022 This is a good question, but would quickly derail the original
- Dukc (21/25) Sep 15 2022 Personally I'd agree with Walter that hex literals are usually
- JN (3/7) Sep 15 2022 I'd remove templates, but since you mention breakages... in such
- bauss (2/13) Sep 15 2022 -release
- IGotD- (12/16) Sep 15 2022 None, that don't get in my way. If a feature is opt-in then if
- ryuukk_ (11/82) Sep 15 2022 - Class as reference type without the *, it should have been like
- Dukc (4/15) Sep 15 2022 Remember, I asked to consider what you would remove __considering
- bauss (2/22) Sep 15 2022 alias uint = u32;
- ryuukk_ (3/4) Sep 15 2022 You have then to import the module everywhere, wich makes the
- IGotD- (3/5) Sep 15 2022 Another thing for D3, global imports. The list is getting longer
- ryuukk_ (6/12) Sep 15 2022 Global import is not what i want, it's actually a very bad idea,
- Walter Bright (2/3) Sep 15 2022 This is deliberately not done for D. It doesn't scale well for larger co...
- jmh530 (5/9) Sep 15 2022 The feature that you want is really the reverse
- bauss (4/14) Sep 15 2022 No, my alias assumes the keywords are actually renamed and being
- bauss (3/7) Sep 15 2022 Could be added to the runtime module and then simply over a
- H. S. Teoh (10/19) Sep 15 2022 That still requires basically *every single D project on the planet* to
- ryuukk_ (11/30) Sep 15 2022 It could be kept as legacy for C compatibility, and new code
- Paul Backus (3/4) Sep 15 2022 [`tuppence`][1], maybe? :)
- xxd (3/7) Sep 15 2022 quite a bit cuter than the definition entry in the urban
- Walter Bright (2/7) Sep 15 2022 C has stdint.h, which I've seen very little uptake on.
- Mike James (4/11) Sep 16 2022 Unless you have to write a lot of code that conforms to MISRA
- Sergey (6/24) Sep 15 2022 I’m pretty surprised that people mentioned betterC.. I expected
- bauss (5/29) Sep 15 2022 I considered writing betterC, but it arguably has a place. I
- Adam D Ruppe (5/7) Sep 15 2022 This is impossible, by definition. Anything that compiles and
- Max Samukha (7/11) Sep 15 2022 The sheer number of D features has never been a problem for us.
- zjh (5/8) Sep 15 2022 There should be a `feature schedule`.
- Dennis (17/21) Sep 15 2022 - Identifier-delimited string literals
- bauss (14/20) Sep 15 2022 I would be all for this if we could get something like
- bauss (6/10) Sep 15 2022 Minor typo here, it should be:
- Walter Bright (4/6) Sep 15 2022 That sounds like a good idea, was tried in C++, and didn't work out very...
- Nick Treleaven (18/29) Sep 15 2022 The non-array forms should be deprecated. What is `(int i...)`
- Dennis (4/9) Sep 15 2022 For my part, without.
- Max Samukha (5/6) Sep 15 2022 Why on this god-forsaken piece of rock do we need this
- Timon Gehr (10/12) Sep 15 2022 +1. This is a great example of both unnecessary language and user
- RazvanN (20/22) Sep 16 2022 There are not a lot of bugs, there are exactly 5 bugs that affect
- Kagamin (5/5) Sep 15 2022 ImportC, betterC, @nogc, nothrow, @safe, @property, nested
- Guillaume Piolat (3/4) Sep 15 2022 real, pure, synchronized, invariant, contracts, @safe, const,
- Guillaume Piolat (4/9) Sep 15 2022 oh and: alias this, template specialization, union, @propert...
- Luhrel (55/106) Sep 16 2022 IMO, some function's attributes should be removed (honestly, they
- H. S. Teoh (38/45) Sep 16 2022 wchar/wstring is occasionally useful for interfacing with some Windows
- Luhrel (2/28) Sep 16 2022 You're probably right. Some ideas are bad ideas ;)
- Ogi (4/5) Sep 17 2022 Non-ASCII characters in identifiers. There is no good reason to
- Dennis (4/7) Sep 17 2022 I don't use non-ASCII identifiers, but you'll have to explain how
- Paul Backus (3/10) Sep 17 2022 I would say not being able to easily type an identifier with the
- Timon Gehr (11/21) Sep 18 2022 There really is no very good excuse for not being able to easily type
- rikki cattermole (4/6) Sep 18 2022 Except it does.
- Ogi (8/15) Sep 20 2022 ```D
- bauss (9/25) Sep 20 2022 How is that different from this?
- Ogi (2/10) Sep 20 2022 Did you try to copy-paste and run my example? It fails.
- max haughton (2/13) Sep 20 2022 Interesting, is there a bug filed for this?
- Quirin Schroll (3/10) Sep 20 2022 It allows for some kind of attacks. You know how ASCII is
- Abdulhaq (5/10) Sep 20 2022 ǝpoɔ ǝɔɹnos uᴉ ʇxǝʇ ǝpoɔᴉun ɹoɟ sǝsn pooƃ ǝɹɐ ǝɹ...
- 0xEAB (6/8) Sep 17 2022 The (already deprecated) «body» keyword.
- Quirin Schroll (351/359) Sep 20 2022 It’s no problem whatsoever when a keyword has multiple meanings
- Nicholas Wilson (9/26) Sep 17 2022 real, specifically x86 80-bit,
- Timon Gehr (11/37) Sep 18 2022 As someone who has had to hack 80 bit floating point support into C++ on...
- Walter Bright (7/17) Sep 18 2022 Just like with cars where there is no substitute for horsepower, there's...
- Walter Bright (2/2) Sep 18 2022 Enzo Ferrari once said: "The secret to better performance is more horsep...
- Nicholas Wilson (2/3) Sep 18 2022 Search for PowerPC DoubleDouble
- Walter Bright (2/6) Sep 18 2022 Yes, thank you. Turned up lots of articles.
- Nicholas Wilson (21/27) Sep 18 2022 Yes there is. Use an algorithm with better convergence properties
- Timon Gehr (6/14) Sep 18 2022 For my project the problem was specifically precision. I needed each
- Nicholas Wilson (5/11) Sep 18 2022 Right and that is well beyond the capability of x86-fp80, which
- Timon Gehr (12/23) Sep 18 2022 Well, I used adaptive precision, float/double/extended/double-double,
- Timon Gehr (21/28) Sep 18 2022 I picked it up back in high school for a CPU-based fractal rendering
- Sergey (2/6) Sep 18 2022 std.json
On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:This is a good question, but would quickly derail the original thread from it's topic, so I decided to start a new one. What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place. ------------------------------------------------------------- Quoting direct replies to the question from the original thread. On Wednesday, 14 September 2022 at 13:30:46 UTC, Adam D Ruppe wrote:But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.Does sometimes justify a language feature, when there are other ways? People often complain that D has too many features. What features would you say are not worth it?On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:On Wednesday, 14 September 2022 at 14:28:40 UTC, Steven Schveighoffer wrote:People often complain that D has too many features. What features would you say are not worth it?ImportC, -betterC, nogc, nothrow, live. These things don't even *work* on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit. To a lesser extent, safe and dip1000 can go too.On 9/14/22 1:58 AM, Walter Bright wrote:On Wednesday, 14 September 2022 at 15:51:17 UTC, Nick Treleaven wrote:People often complain that D has too many features. What features would you say are not worth it?There's a difference between "not worth adding" and "not worth keeping". Removing features needs a very high bar to make sense. Adding features also needs a high bar, considering that it's more difficult to remove later than it is to not add it. That being said, if binary literals weren't in the language, I'd be fine adding them. They don't cost anything, and add a way to write code that is clearer in some cases. If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd *want* to remove. D's features are pretty nice. -SteveOn Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:Template constraints. Horrible error messages (though better than they were) and confusing to work out which overload matches. They make documentation complicated. Just use static if and static assert instead to solve all these problems.But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.Does sometimes justify a language feature, when there are other ways? People often complain that D has too many features. What features would you say are not worth it?
Sep 15 2022
Dukc <ajieskola gmail.com> On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.Personally I'd agree with Walter that hex literals are usually better and the possiblity for a library solution makes binary literals even less necessary. I wouldn't personally miss binary literals. But all the contrary feedback in that thread convinced me that many would, so it'd be a bad removal especially considering how simple it is for the compiler/spec. Other ideas: - All the stuff that is deprecated already, according to the removal schelude. - ` live`. It's a good experimental concept for a future DIP to build on, but does not currently justify it's complexity in a real project. - ` property`, as said in another thread. well maybe not removed, but changed to a no-op. With a deprecation period, warnings given for uses that depend on current semantics of it. - `lazy`, if DIP1033 is awaken and accepted. With a deprecation period of course. - Old alias syntax `alias originalName Alias`. I'd prefer `alias this` to also use the new syntax. Again, deprecation period needed.
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.I'd remove templates, but since you mention breakages... in such case I'd say contracts, finalizers and possibly exceptions.
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):-releaseOn 9/13/2022 7:56 PM, Steven Schveighoffer wrote:But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.Does sometimes justify a language feature, when there are other ways? People often complain that D has too many features. What features would you say are not worth it?
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.None, that don't get in my way. If a feature is opt-in then if you don't use them there is no big deal for me. What is a big deal for me are features that don't work or are half finished. Example of this are shared, safe, live (not a comprehensive memory management feature) and probably ImportC. I'm starting to come to the conclusion that the D project is broken and must be revamped, that is D3. I think that D should be forked with new people and management. Hopefully this enables more focus in the project and that D can evolve in a more usable language that isn't full of holes and half thought out features.
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):- Class as reference type without the *, it should have been like - Exception Handling (taking inspiration from Swift would be interesting) - property apparently, i forgot this was a thing until i saw the post yesterday - enum, replace this and make better enum with pattern matching and .Enum - byte, short, int, long, give me (u*8, u*16, u*32, u*64, * = either nothing or int)On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:This is a good question, but would quickly derail the original thread from it's topic, so I decided to start a new one. What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place. ------------------------------------------------------------- Quoting direct replies to the question from the original thread. On Wednesday, 14 September 2022 at 13:30:46 UTC, Adam D Ruppe wrote:But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.Does sometimes justify a language feature, when there are other ways? People often complain that D has too many features. What features would you say are not worth it?On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:On Wednesday, 14 September 2022 at 14:28:40 UTC, Steven Schveighoffer wrote:People often complain that D has too many features. What features would you say are not worth it?ImportC, -betterC, nogc, nothrow, live. These things don't even *work* on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit. To a lesser extent, safe and dip1000 can go too.On 9/14/22 1:58 AM, Walter Bright wrote:On Wednesday, 14 September 2022 at 15:51:17 UTC, Nick Treleaven wrote:People often complain that D has too many features. What features would you say are not worth it?There's a difference between "not worth adding" and "not worth keeping". Removing features needs a very high bar to make sense. Adding features also needs a high bar, considering that it's more difficult to remove later than it is to not add it. That being said, if binary literals weren't in the language, I'd be fine adding them. They don't cost anything, and add a way to write code that is clearer in some cases. If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd *want* to remove. D's features are pretty nice. -SteveOn Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:Template constraints. Horrible error messages (though better than they were) and confusing to work out which overload matches. They make documentation complicated. Just use static if and static assert instead to solve all these problems.But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.Does sometimes justify a language feature, when there are other ways? People often complain that D has too many features. What features would you say are not worth it?
Sep 15 2022
On Thursday, 15 September 2022 at 10:50:11 UTC, ryuukk_ wrote:- Class as reference type without the *, it should have been like Go since day 1, so no confusion instead of trying to be - Exception Handling (taking inspiration from Swift would be interesting) - property apparently, i forgot this was a thing until i saw the post yesterday - enum, replace this and make better enum with pattern matching and .Enum - byte, short, int, long, give me (u*8, u*16, u*32, u*64, * = either nothing or int)Remember, I asked to consider what you would remove __considering backwards compatibility__. You can't be serious about removing all of these, it'd break literally everything.
Sep 15 2022
On Thursday, 15 September 2022 at 11:11:47 UTC, Dukc wrote:On Thursday, 15 September 2022 at 10:50:11 UTC, ryuukk_ wrote:alias uint = u32;- Class as reference type without the *, it should have been like Go since day 1, so no confusion instead of trying to be - Exception Handling (taking inspiration from Swift would be interesting) - property apparently, i forgot this was a thing until i saw the post yesterday - enum, replace this and make better enum with pattern matching and .Enum - byte, short, int, long, give me (u*8, u*16, u*32, u*64, * = either nothing or int)Remember, I asked to consider what you would remove __considering backwards compatibility__. You can't be serious about removing all of these, it'd break literally everything.
Sep 15 2022
On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 15 2022
On Thursday, 15 September 2022 at 12:19:28 UTC, ryuukk_ wrote:You have then to import the module everywhere, wich makes the feature i want a painful nightmareAnother thing for D3, global imports. The list is getting longer :).
Sep 15 2022
On Thursday, 15 September 2022 at 12:20:51 UTC, IGotD- wrote:On Thursday, 15 September 2022 at 12:19:28 UTC, ryuukk_ wrote:Global import is not what i want, it's actually a very bad idea, it encourages poor practices, it'll lead to poor build speed and bloated global scope What i want is modernizing the builtin types instead of keeping imaginary english names that originate from C eraYou have then to import the module everywhere, wich makes the feature i want a painful nightmareAnother thing for D3, global imports. The list is getting longer :).
Sep 15 2022
On 9/15/2022 5:20 AM, IGotD- wrote:Another thing for D3, global imports.This is deliberately not done for D. It doesn't scale well for larger code bases.
Sep 15 2022
On Thursday, 15 September 2022 at 12:19:28 UTC, ryuukk_ wrote:On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:The feature that you want is really the reverse alias u32 = uint; Can't you hack your Druntime to put it in so that you don't want to import them from everywhere?alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 15 2022
On Thursday, 15 September 2022 at 12:27:23 UTC, jmh530 wrote:On Thursday, 15 September 2022 at 12:19:28 UTC, ryuukk_ wrote:No, my alias assumes the keywords are actually renamed and being deprecated. Yours still rely on the old keywords existing.On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:The feature that you want is really the reverse alias u32 = uint; Can't you hack your Druntime to put it in so that you don't want to import them from everywhere?alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 15 2022
On Thursday, 15 September 2022 at 13:20:06 UTC, bauss wrote:[snip] No, my alias assumes the keywords are actually renamed and being deprecated. Yours still rely on the old keywords existing.Yeah. I just meant that he could have this feature now if he wanted to, no deprecation and renaming needed. (which you know, of course).
Sep 15 2022
On Thursday, 15 September 2022 at 13:27:08 UTC, jmh530 wrote:On Thursday, 15 September 2022 at 13:20:06 UTC, bauss wrote:Yeah personally I have aliases like these now: ```d alias verysmallint = byte; alias smallint = short; alias normalint = int; alias largeint = long; alias megaint = cent; ``` (This is a joke.)[snip] No, my alias assumes the keywords are actually renamed and being deprecated. Yours still rely on the old keywords existing.Yeah. I just meant that he could have this feature now if he wanted to, no deprecation and renaming needed. (which you know, of course).
Sep 15 2022
On Thursday, 15 September 2022 at 12:19:28 UTC, ryuukk_ wrote:On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:Could be added to the runtime module and then simply over a couple years the aliases will be deprecated.alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 15 2022
On Thu, Sep 15, 2022 at 01:18:30PM +0000, bauss via Digitalmars-d wrote:On Thursday, 15 September 2022 at 12:19:28 UTC, ryuukk_ wrote:That still requires basically *every single D project on the planet* to be rewritten to the new type names over the deprecation period. Not practical. And seriously, guys, these are just *arbitrary names* for built-in types. At the cost of wholesale breakage of all existing code? Bikeshedding at its finest. This is DOA. T -- Verbing weirds language. -- Calvin (& Hobbes)On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:Could be added to the runtime module and then simply over a couple years the aliases will be deprecated.alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 15 2022
On Thursday, 15 September 2022 at 19:04:33 UTC, H. S. Teoh wrote:On Thu, Sep 15, 2022 at 01:18:30PM +0000, bauss via Digitalmars-d wrote:It could be kept as legacy for C compatibility, and new code could naturally transition to the new types whenever they are ready I'm not a language dev, so i don't understand the implications of such features I don't see how it's bikeshedding, it brings consistence for primitives What's gonna be the name after `cent`? when other modern languages will have `uint256`, we will be left alone in the dark with inconsistenciesOn Thursday, 15 September 2022 at 12:19:28 UTC, ryuukk_ wrote:That still requires basically *every single D project on the planet* to be rewritten to the new type names over the deprecation period. Not practical. And seriously, guys, these are just *arbitrary names* for built-in types. At the cost of wholesale breakage of all existing code? Bikeshedding at its finest. This is DOA. TOn Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:Could be added to the runtime module and then simply over a couple years the aliases will be deprecated.alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 15 2022
On Thursday, 15 September 2022 at 20:19:38 UTC, ryuukk_ wrote:What's gonna be the name after `cent`?[`tuppence`][1], maybe? :) [1]: https://www.youtube.com/watch?v=XHrRxQVUFN4
Sep 15 2022
On Thursday, 15 September 2022 at 22:10:10 UTC, Paul Backus wrote:On Thursday, 15 September 2022 at 20:19:38 UTC, ryuukk_ wrote:quite a bit cuter than the definition entry in the urban dictionaryWhat's gonna be the name after `cent`?[`tuppence`][1], maybe? :) [1]: https://www.youtube.com/watch?v=XHrRxQVUFN4
Sep 15 2022
On 9/15/2022 5:19 AM, ryuukk_ wrote:On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:C has stdint.h, which I've seen very little uptake on.alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 15 2022
On Friday, 16 September 2022 at 05:00:31 UTC, Walter Bright wrote:On 9/15/2022 5:19 AM, ryuukk_ wrote:Unless you have to write a lot of code that conforms to MISRA C... :-) -=mike=-On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:C has stdint.h, which I've seen very little uptake on.alias uint = u32;You have then to import the module everywhere, wich makes the feature i want a painful nightmare
Sep 16 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):I’m pretty surprised that people mentioned betterC.. I expected improvements and development of that part. AFAIK it is the easiest way to use D in WebAssembly, also a lot of great and high performant libs (like mir) working in betterC mode only..On 9/13/2022 7:56 PM, Steven Schveighoffer wrote: On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:People often complain that D has too many features. What features would you say are not worth it?ImportC, -betterC, nogc, nothrow, live. These things don't even *work* on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit. If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd *want* to remove. D's features are pretty nice. -Steve
Sep 15 2022
On Thursday, 15 September 2022 at 11:15:21 UTC, Sergey wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:I considered writing betterC, but it arguably has a place. I think the problem is that it is a subset and it shouldn't be. It should just be possible to be barebone without resorting to a subset of the language.On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):I’m pretty surprised that people mentioned betterC.. I expected improvements and development of that part. AFAIK it is the easiest way to use D in WebAssembly, also a lot of great and high performant libs (like mir) working in betterC mode only..On 9/13/2022 7:56 PM, Steven Schveighoffer wrote: On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:People often complain that D has too many features. What features would you say are not worth it?ImportC, -betterC, nogc, nothrow, live. These things don't even *work* on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit. If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd *want* to remove. D's features are pretty nice. -Steve
Sep 15 2022
On Thursday, 15 September 2022 at 11:15:21 UTC, Sergey wrote:a lot of great and high performant libs (like mir) working in betterC mode only..This is impossible, by definition. Anything that compiles and runs with -betterC works just as well without it (this is actually one of the few good things about its design, it guarantees compatibility in this way).
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.The sheer number of D features has never been a problem for us. Inconsistencies, poor feature compatibility, bugs, incomplete implementations have always been. Removing binary literals, ` property`, `shared`, etc would produce zero value (unless the resultant compiler simplifications made it easier to fix real problems).
Sep 15 2022
On Thursday, 15 September 2022 at 11:47:06 UTC, Max Samukha wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:Inconsistencies, poor feature compatibility, bugs, incomplete implementations have always been.There should be a `feature schedule`. Or: `Unimplement feature list`. In this way, you can add it bit by bit. Instead of reducing `existing feature`!
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.- Identifier-delimited string literals (https://dlang.org/dips/1026) - Typesafe variadic arguments (https://github.com/dlang/dmd/pull/11124) - `lazy` - `alias this` inside a class - old `alias type identifier` notation instead of `alias identifier = type` - `extern(C++, identifier)` (Mathias Lang did not manage to convince Walter at DConf 2022 though) - `__FUNCTION__` and `__PRETTY_FUNCTION__` - `this(this)` (postblit is superseded by copy constructor, though there are still a lot of bugs) - Redundant `__traits` such as isFloating, isIntegral, isScalar, isStaticArray, isUnsigned Not 100% sure about each one, but these are my candidates
Sep 15 2022
On Thursday, 15 September 2022 at 13:43:01 UTC, Dennis wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:I would be all for this if we could get something like opImplCast() which would basically be the same as opCast() but without requiring cast. I believe the operator overloads must be static for it to work properly with ex. `Foo foo = 100;`. ``` Foo foo = 100; // Would trigger static void opImplCast(T)(T value) where T is int. int a = foo; // Would trigger ex. static T opImplCast(T)(Foo instance) where T is int ``` You should of course be able to be explicit about types like `int opImplCast(Foo instance);`What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.- `alias this` inside a class
Sep 15 2022
On Thursday, 15 September 2022 at 14:10:07 UTC, bauss wrote:``` Foo foo = 100; // Would trigger static void opImplCast(T)(T value) where T is int. ```Minor typo here, it should be: ``` Foo foo = 100; // Would trigger static Foo opImplCast(T)(T value) where T is int. ```
Sep 15 2022
On 9/15/2022 7:10 AM, bauss wrote:I would be all for this if we could get something like opImplCast() which would basically be the same as opCast() but without requiring cast.That sounds like a good idea, was tried in C++, and didn't work out very well. The trouble is it works great in simple cases, but with more complex overloads nobody can figure out what's happening.
Sep 15 2022
On Friday, 16 September 2022 at 05:18:01 UTC, Walter Bright wrote:On 9/15/2022 7:10 AM, bauss wrote:one language, doesn't mean it does in another.I would be all for this if we could get something like opImplCast() which would basically be the same as opCast() but without requiring cast.That sounds like a good idea, was tried in C++, and didn't work out very well. The trouble is it works great in simple cases, but with more complex overloads nobody can figure out what's happening.
Sep 15 2022
On Friday, 16 September 2022 at 06:34:01 UTC, bauss wrote:On Friday, 16 September 2022 at 05:18:01 UTC, Walter Bright wrote:Oh and it's certainly much better than alias this.On 9/15/2022 7:10 AM, bauss wrote:one language, doesn't mean it does in another.I would be all for this if we could get something like opImplCast() which would basically be the same as opCast() but without requiring cast.That sounds like a good idea, was tried in C++, and didn't work out very well. The trouble is it works great in simple cases, but with more complex overloads nobody can figure out what's happening.
Sep 15 2022
On Thursday, 15 September 2022 at 13:43:01 UTC, Dennis wrote:- Typesafe variadic arguments (https://github.com/dlang/dmd/pull/11124)The non-array forms should be deprecated. What is `(int i...)` even useful for?- `lazy`With or without Walter's idea of a delegate parameter returning T automatically wrapping an argument of type T into a delegate? That doesn't seem to be implemented: implicitlazy.d(10): Error: function `implicitlazy.f(int delegate() d)` is not callable using argument types `(int)`- `alias this` inside a classIt's fine if the class is `final`.- old `alias type identifier` notation instead of `alias identifier = type`+1- `__FUNCTION__` and `__PRETTY_FUNCTION__`Are there traits for these instead?- `this(this)` (postblit is superseded by copy constructor, though there are still a lot of bugs)The docs have: WARNING: The postblit is considered legacy and is not recommended for new code So we could probably add it to the deprecate.dd list for future deprecation when copy ctor is robust enough.- Redundant `__traits` such as isFloating, isIntegral, isScalar, isStaticArray, isUnsignedRedundant because of Phobos? Isn't that going to cause lots of template instantiations?
Sep 15 2022
On Thursday, 15 September 2022 at 17:56:57 UTC, Nick Treleaven wrote:For my part, without.- `lazy`With or without Walter's idea of a delegate parameter returning T automatically wrapping an argument of type T into a delegate?I think there's `__traits(parent, {})` inside a function body.- `__FUNCTION__` and `__PRETTY_FUNCTION__`Are there traits for these instead?
Sep 15 2022
On Thursday, 15 September 2022 at 19:19:13 UTC, Dennis wrote:
I think there's `__traits(parent, {})` inside a function body.
Why on this god-forsaken piece of rock do we need this
abomination while we could easily have a self, __self, scope,
__scope, __traits(scope) or whatever to refer to the current
scope?
Sep 15 2022
On 15.09.22 15:43, Dennis wrote:- `extern(C++, identifier)` (Mathias Lang did not manage to convince Walter at DConf 2022 though)+1. This is a great example of both unnecessary language and user complexity: - It's basically never what you want (the same namespace imported from different D modules will clash with itself). - It clashes with actually useful features, now people sometimes have to write the unsightly `extern(C++, (identifier))` to hack around the existence of a feature that does not need to exist in the first place. - It introduces new unexpected scoping rules. Kill it. (Or fix it I guess, but don't just leave it the way it is.)
Sep 15 2022
On Thursday, 15 September 2022 at 13:43:01 UTC, Dennis wrote:- `this(this)` (postblit is superseded by copy constructor, though there are still a lot of bugs)There are not a lot of bugs, there are exactly 5 bugs that affect copy constructors exclusively (there are others that manifest in conjunction with a copy constructor, but those manifested with the postblit as well): https://issues.dlang.org/show_bug.cgi?id=22614 (arguably, not a problem of copy constructors - see comments in bug report) https://issues.dlang.org/show_bug.cgi?id=22239 (not obvious how to fix) https://issues.dlang.org/show_bug.cgi?id=21613 (PR submitted) https://issues.dlang.org/show_bug.cgi?id=20876 (doesn't necessarily block migration, it's just that the error message is not ideal) https://issues.dlang.org/show_bug.cgi?id=20208 (affecting c++ interoperability) From the list above, the only issue that is blocking the transition from postblit to copy constructor is 22239. So there is exactly 1 bug that impedes the deprecation of postblits in favor of the copy constructor, so please do not spread fear of using the copy constructor.
Sep 16 2022
ImportC, betterC, nogc, nothrow, safe, property, nested comments, delimited strings, case labels, new alias syntax. The new alias syntax works well for simple symbol alias, but feels less natural for more complex types so I actually went to the old syntax for all my aliases.
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you?real, pure, synchronized, invariant, contracts, safe, const, TLS, unsigned integers :)
Sep 15 2022
On Friday, 16 September 2022 at 00:41:25 UTC, Guillaume Piolat wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:oh and: alias this, template specialization, union, propert... Thank god it's not up to me.What features could be removed from D if it were up to you?real, pure, synchronized, invariant, contracts, safe, const, TLS, unsigned integers :)
Sep 15 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.IMO, some function's attributes should be removed (honestly, they just spoil my view when coding) : - ` nogc` : I would love a Rust-style (dip1000 ?) "automatic free" system, or even better, we could implement a way to decide how the memory is managed : 1. Free the memory (call `free()`) once the pointer's lifetime has ended (Rust's style) 2. Do not free memory at all (DMD's compiler style), the pointer is added to the GC's list. Like that we can manually call `GC.free()` when we want to. 3. Reuse memory : instead of calling `free()`, store the type and the pointer a list, and reuse the pointer if a `new` class of the same type is created. ([Zink's style](https://www.supergoodcode.com/SP33D/) ?) - ` safe` : Should be the default - ` system` & ` trusted` : I would entirely remove them, 'cause currently I just add ` trusted` when I want to call an unsafe function from a ` safe` function (mostly when it's an external C function). (Maybe I just don't see the goal of these attributes.) I would also remove `wchar` and `dchar` (and [`d`/`w`]`string`), and go full Unicode for the `char` type, like in Rust. However, this would be a little challenging when slicing : 1. Panic when slicing in the "middle" of a character (Rust does it this way) 2. Throw an Exception 3. Change `char` size to 4 bytes, so "`char` = `dchar`" by default Also, I won't miss any implementation defined feature. But obviously, these are ideas and removing any of these will break people's code. ---- My answer to other people's points of view : On Thursday, 15 September 2022 at 09:11:15 UTC, Dukc wrote:- All the stuff that is deprecated already, according to the removal schelude. - ` live`. It's a good experimental concept for a future DIP to build on, but does not currently justify it's complexity in a real project.+2- ` property`, as said in another thread. well maybe not removed, but changed to a no-op. With a deprecation period, warnings given for uses that depend on current semantics of it.Don't remove it, improve it ! It would be very useful when creating a class which internally calls some C functions.- `lazy`, if DIP1033 is awaken and accepted. With a deprecation period of course.+1, I never ever used it.- Old alias syntax `alias originalName Alias`. I'd prefer `alias this` to also use the new syntax. Again, deprecation period needed.+1, I also would love a `alias this = x;` syntax. On Thursday, 15 September 2022 at 09:12:52 UTC, JN wrote:I'd remove templates, but since you mention breakages... in such case I'd say contracts, finalizers and possibly exceptions.WTF, no ! Templates are why I use D instead of Java or C++ : they are well made. On Thursday, 15 September 2022 at 10:50:11 UTC, ryuukk_ wrote:- Class as reference type without the *, it should have been like Go since day 1, so no confusion instead of trying to be - Exception Handling (taking inspiration from Swift would be interesting) - property apparently, i forgot this was a thing until i saw the post yesterday - enum, replace this and make better enum with pattern matching and .Enum - byte, short, int, long, give me (u\*8, u\*16, u\*32, u\*64, * = either nothing or int)I don't agree with you, at all. Just use Rust. On Thursday, 15 September 2022 at 13:43:01 UTC, Dennis wrote:- Typesafe variadic arguments (https://github.com/dlang/dmd/pull/11124) - `lazy`+2- `alias this` inside a classNo.- old `alias type identifier` notation instead of `alias identifier = type` - `extern(C++, identifier)` (Mathias Lang did not manage to convince Walter at DConf 2022 though) - `__FUNCTION__` and `__PRETTY_FUNCTION__`I agree. However, D doesn't have a `__FUNCTION__` equivalent. (`__FUNCTION__` returns `mymodulee.func` and `__traits(identifier, func)` returns `func`)- `this(this)` (postblit is superseded by copy constructor, though there are still a lot of bugs)+1- Redundant `__traits` such as isFloating, isIntegral, isScalar, isStaticArray, isUnsignedMaybe. On Friday, 16 September 2022 at 00:41:25 UTC, Guillaume Piolat wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:Thank god.What features could be removed from D if it were up to you?real, pure, synchronized, invariant, contracts, safe, const, TLS, unsigned integers :) [...] alias this, template specialization, union, property Thank god it's not up to me.
Sep 16 2022
On Fri, Sep 16, 2022 at 09:24:40PM +0000, Luhrel via Digitalmars-d wrote: [...]I would also remove `wchar` and `dchar` (and [`d`/`w`]`string`), and go full Unicode for the `char` type, like in Rust.wchar/wstring is occasionally useful for interfacing with some Windows APIs. `dchar` is needed for representing a full Unicode code point (which can go up to 0x10_ffff). But `dstring` is pretty much useless.However, this would be a little challenging when slicing : 1. Panic when slicing in the "middle" of a character (Rust does it this way)The problem is that what we think of as a "character" is *not* what the Unicode standard calls a "character". Well actually, Unicode doesn't even use the word "character"; it has something called "code points", which people mistakenly assume is the same as our concept of "character" (unfortunately, this is not true). A `char` corresponds with a "code unit" in UTF-8; one or more code units correspond with a single code point. However, what we think of as a "character" may consist of *multiple* code points: for example, the sequence \u0041\u0301 consists of *two* Unicode code points, but a single displayed character (which Unicode calls a grapheme). The problem of slicing in the "middle" of a "character" will occur even if you don't allow breaking apart code units that encode a single code point. For example, the above sequence "\u0041\u0301" can be legally split into two separate code points, but that would also break the grapheme. The only way to avoid this is to allow slicing only between grapheme boundaries... ... unfortunately, computing grapheme boundaries is non-trivial in Unicode and introduces a big performance hit if you overuse it. Most code actually should *not* care about any of the above; they should treat strings as opaque binary data and only use Unicode library functions to manipulate them. In the rare case when you actually need to parse individual elements in the string, you can iterate over graphemes with std.uni.byGrapheme. (Or iterate over code points, depending on what your code is trying to do.)2. Throw an ExceptionBad idea. In fact, we worked really hard to try to get rid of this behaviour in Phobos, and I'm not sure if we're 100% there yet.3. Change `char` size to 4 bytes, so "`char` = `dchar`" by defaultThis would imply extending autodecoding to every string operation on UTF-8 data. Autodecoding is something we've been trying to get rid of, not keep, much less extend. :-P T -- If you're not part of the solution, you're part of the precipitate.
Sep 16 2022
On Friday, 16 September 2022 at 21:50:53 UTC, H. S. Teoh wrote:On Fri, Sep 16, 2022 at 09:24:40PM +0000, Luhrel via Digitalmars-d wrote: [...]You're probably right. Some ideas are bad ideas ;)I would also remove `wchar` and `dchar` (and [`d`/`w`]`string`), and go full Unicode for the `char` type, like in Rust.wchar/wstring is occasionally useful for interfacing with some Windows APIs. `dchar` is needed for representing a full Unicode code point (which can go up to 0x10_ffff). But `dstring` is pretty much useless. [...] The problem is that what we think of as a "character" is *not* what the Unicode standard calls a "character". [...] they should treat strings as opaque binary data and only use Unicode library functions to manipulate them. [...] Bad idea. In fact, we worked really hard to try to get rid of this behaviour in Phobos, and I'm not sure if we're 100% there yet. [...] This would imply extending autodecoding to every string operation on UTF-8 data. Autodecoding is something we've been trying to get rid of, not keep, much less extend. :-P T
Sep 16 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you?Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.
Sep 17 2022
On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.I don't use non-ASCII identifiers, but you'll have to explain how e.g. using `π` instead of `pi` results in bugs or maintenance burden.
Sep 17 2022
On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:I would say not being able to easily type an identifier with the keys on one's keyboard counts as a maintenance burden.Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.I don't use non-ASCII identifiers, but you'll have to explain how e.g. using `π` instead of `pi` results in bugs or maintenance burden.
Sep 17 2022
On 18.09.22 03:14, Paul Backus wrote:On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:There really is no very good excuse for not being able to easily type such common characters, provided one is able to easily type at all. Programmers of all people should be able to figure it out. In any case, not all identifiers are English. As Ali likes to point out, some Turkish characters have no obvious ASCII substitute and substituting visually similar characters may result in curse words in identifiers. In such cases, all of the maintainers know how to type in Turkish. People are sometimes prone to dismissing the validity of other cultures. I am glad D's lexer is not.On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:I would say not being able to easily type an identifier with the keys on one's keyboard counts as a maintenance burden.Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.I don't use non-ASCII identifiers, but you'll have to explain how e.g. using `π` instead of `pi` results in bugs or maintenance burden.
Sep 18 2022
On 18/09/2022 7:32 PM, Timon Gehr wrote:People are sometimes prone to dismissing the validity of other cultures. I am glad D's lexer is not.Except it does. The definitions it uses are an unknown amount of years old (potentially 20 years old) and have long since been superseded.
Sep 18 2022
On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:```D int μ = 42; void main() { int µ = 69; assert(μ == 69); } ```Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.I don't use non-ASCII identifiers, but you'll have to explain how e.g. using `π` instead of `pi` results in bugs or maintenance burden.
Sep 20 2022
On Tuesday, 20 September 2022 at 07:13:45 UTC, Ogi wrote:On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:How is that different from this? ```D int a = 42; void main() { int a = 69; assert(a == 69); } ```On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:```D int μ = 42; void main() { int µ = 69; assert(μ == 69); } ```Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.I don't use non-ASCII identifiers, but you'll have to explain how e.g. using `π` instead of `pi` results in bugs or maintenance burden.
Sep 20 2022
On Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:
How is that different from this?
```D
int a = 42;
void main() {
int a = 69;
assert(a == 69);
}
```
Did you try to copy-paste and run my example? It fails.
Sep 20 2022
On Tuesday, 20 September 2022 at 07:44:37 UTC, Ogi wrote:On Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:Interesting, is there a bug filed for this?How is that different from this? ```D int a = 42; void main() { int a = 69; assert(a == 69); } ```Did you try to copy-paste and run my example? It fails.
Sep 20 2022
On Tuesday, 20 September 2022 at 08:47:51 UTC, max haughton wrote:On Tuesday, 20 September 2022 at 07:44:37 UTC, Ogi wrote:I'm guessing there are two different unicode glyphs here, mu and micro sign, they look very similar in this fontOn Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:Interesting, is there a bug filed for this?How is that different from this? ```D int a = 42; void main() { int a = 69; assert(a == 69); } ```Did you try to copy-paste and run my example? It fails.
Sep 20 2022
On Tuesday, 20 September 2022 at 08:47:51 UTC, max haughton wrote:On Tuesday, 20 September 2022 at 07:44:37 UTC, Ogi wrote:No bug here, that’s two Unicode characters that look identical in many fonts: Greek Small Letter Mu (U+03BC) and Micro Sign (U+00B5). It shouldn’t come as a surprise that some characters in Unicode look identical. But this case is more interesting because you don’t expect the Greek mu to have a twin brother.On Tuesday, 20 September 2022 at 07:17:12 UTC, bauss wrote:Interesting, is there a bug filed for this?How is that different from this? ```D int a = 42; void main() { int a = 69; assert(a == 69); } ```Did you try to copy-paste and run my example? It fails.
Sep 20 2022
On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:It allows for some kind of attacks. You know how ASCII is different from АЅСІІ? The latter is Cyrillic letters.Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.I don't use non-ASCII identifiers, but you'll have to explain how e.g. using `π` instead of `pi` results in bugs or maintenance burden.
Sep 20 2022
On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:ǝpoɔ ǝɔɹnos uᴉ ʇxǝʇ ǝpoɔᴉun ɹoɟ sǝsn pooƃ ǝɹɐ ǝɹǝɥ┴ Seriously though, e.g. I was checking that characters fell in the range of alpha to omega, and used the actual unicode chars to do it.What features could be removed from D if it were up to you?Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.
Sep 20 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you?The (already deprecated) «body» keyword. BUT: only because it’s already been superseded by «do»Please consider the breakage that would result from the removalLegacy code (that doesn’t compile without warnings anymore). Also it’s one step towards more ambiguity (because «do» got several meanings now).
Sep 17 2022
On Saturday, 17 September 2022 at 19:58:24 UTC, 0xEAB wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:It’s no problem whatsoever when a keyword has multiple meanings if those meanings are reasonably distinct. Best example is `in`: It serves as a storage class (`in` parameter), it serves as a precondition contract, and it serves as an operator (in tango with `!in`). Sometimes, people complain that `static` is too overloaded. It means “needs no context” or “runs at compile-time” or “(variable value) survives through calls”. I’ve gone through all the keywords. Apart from special tokens and fundamental types (except `void`), there are 36 with a unique semantics and 40 with multiple semantics. Note that those with “unique” are those for which I don’t know of multiple. It could be that I missed some. The full list: | Keyword | Uses | Notes | |-----------------------|--------------:|-------------------------------------------------------------------------------------------------------------------------------| | `abstract` | 2 | abstract method, abstract class | | `alias` | 2 | alias, alias – this | | `align` | 1 | | | `asm` | 1 | | | `assert` | 2 | assert, static assert | | `auto` | 2 | storage class, auto ref | | `body` | 0 | | | `bool` | type | | | `break` | 1 | | | `byte` | type | | | `case` | 2 | switch – case, goto case | | `cast` | 1 | | | `catch` | 1 | | | `cdouble` | type | | | `cent` | type | | | `cfloat` | type | | | `char` | type | | | `class` | 2 | class declaration, anonymous class object | | `const` | 2 | type ctor, storage class | | `continue` | 1 | | | `creal` | type | | | `dchar` | type | | | `debug` | 2 | debug (v), debug = v | | `default` | 2 | switch – default, goto default; | | `delegate` | 2 | lambda introducer, function ptr type | | `delete` | 0 | | | `deprecated` | 1 | | | `do` | 2 | do – while, function body introducer | | `double` | type | | | `else` | ≥ 4 | if – else, static if – else, version – else, debug – else | | `enum` | 2 | enumeration types, enum values | | `export` | 1 | | | `extern` | 1 | | | `false` | 1 | | | `final` | 2 | final class, final method | | `finally` | 1 | | | `float` | type | | | `for` | 1 | | | `foreach` | 2 | statement, static foreach | | `foreach_reverse` | 2 | statement, static foreach_reverse | | `function` | 2 | lambda introducer, function ptr type | | `goto` | 2 | goto label, goto case/default | | `idouble` | type | | | `if` | 3 | statement, static if, template constraint | | `ifloat` | type | | | `immutable` | 2 | type ctor, storage class | | `import` | 1 | | | `in` | 3 | storage class, contract, operator | | `inout` | 2 | type ctor, storage class | | `int` | type | | | `interface` | 2 | interface type declaration, is(T ==interface) | | `invariant` | 1 | | | `ireal` | type | | | `is` | 2 | is operator, is expression | | `lazy` | 1 | | | `long` | type | | | `macro` | 0 | | | `mixin` | 2 | string mixin, mixin template | | `module` | 1 | | | `new` | 1 | | | `nothrow` | 1 | | | `null` | 1 | | | `out` | 2 | storage class, contract | | `override` | 1 | | | `package` | 2 | package declaration, visibility attribute | | `pragma` | 1 | | | `private` | 1 | | | `protected` | 1 | | | `public` | 1 | | | `pure` | 1 | | | `real` | type | | | `ref` | 2 | storage class, auto ref | | `return` | 2 | statement, storage class | | `scope` | 2 | storage class, scope guards | | `shared` | 2 | type ctor, storage class | | `short` | type | | | `static` | ≥ 5 | static variable, static if, static foreach, inner type/function w/o context, static assert | | `struct` | 3 | struct type declaration, is(T == struct), unnamed struct components | | `super` | 2 | super subobject, ctor call | | `switch` | 1 | | | `synchronized` | 1 | | | `template` | 2 | template, mixin template | | `this` | 3 | this object, typeof(this), forwarding ctor | | `throw` | 2 | throw expression, attribute | | `true` | 1 | | | `try` | 1 | | | `typeid` | 1 | | | `typeof` | 1 | | | `ubyte` | type | | | `ucent` | type | | | `uint` | type | | | `ulong` | type | | | `union` | 3 | union type declaration, is(T == union), unnamed union components | | `unittest` | 2 | unit tests, version (unittest) | | `ushort` | type | | | `version` | 2 | version (v), version = v | | `void` | 2 | type, void init | | `wchar` | type | | | `while` | 1 | while loop, do – while loop | | `with` | 1 | | | `__FILE__` | special token | | | `__FILE_FULL_PATH__` | special token | | | `__MODULE__` | special token | | | `__LINE__` | special token | | | `__FUNCTION__` | special token | | | `__PRETTY_FUNCTION__` | special token | | | `__gshared` | 1 | | | `__traits` | 1 | | | `__vector` | 1 | | | `__parameters` | 1 | | (Anyone here is free to improve on this list. Use it for whatever you want.)What features could be removed from D if it were up to you?The (already deprecated) «body» keyword. BUT: only because it’s already been superseded by «do»Please consider the breakage that would result from the removalLegacy code (that doesn’t compile without warnings anymore). Also it’s one step towards more ambiguity (because «do» got several meanings now).
Sep 20 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):real, specifically x86 80-bit, * its slow, you can't vectorise it * the extra precision isn't much use * use is often unintentional, and when it is the intention is almost always misguided. If you have precision problems a couple of bits of extra precision won't make up for a horrible convergence rate and if it does, you probably need an arbitrary precision type anyway.On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:This is a good question, but would quickly derail the original thread from it's topic, so I decided to start a new one. What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.Does sometimes justify a language feature, when there are other ways? People often complain that D has too many features. What features would you say are not worth it?
Sep 17 2022
On 18.09.22 08:47, Nicholas Wilson wrote:On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:As someone who has had to hack 80 bit floating point support into C++ on Windows with inline assembly, I am glad it is supported. Unintentional use should be curbed though. Also, the added precision is more than a couple of bits and sometimes you just need that resolution. 80 bit floats are faster than arbitrary precision floats, so it provides a nice performance boost in that region, before you have to fall back on software solutions. (There is a trick where you use two or more doubles to represent a number with more mantissa bits though and it is possible that with AVX, performance may be competitive with 80 bit floats, but vectorising that code manually is more work.)On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):real, specifically x86 80-bit, * its slow, you can't vectorise it * the extra precision isn't much use * use is often unintentional, and when it is the intention is almost always misguided. If you have precision problems a couple of bits of extra precision won't make up for a horrible convergence rate and if it does, you probably need an arbitrary precision type anyway.On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:This is a good question, but would quickly derail the original thread from it's topic, so I decided to start a new one. What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.Does sometimes justify a language feature, when there are other ways? People often complain that D has too many features. What features would you say are not worth it?
Sep 18 2022
On 9/18/2022 12:50 AM, Timon Gehr wrote:As someone who has had to hack 80 bit floating point support into C++ on Windows with inline assembly, I am glad it is supported. Unintentional use should be curbed though. Also, the added precision is more than a couple of bits and sometimes you just need that resolution. 80 bit floats are faster than arbitrary precision floats, so it provides a nice performance boost in that region, before you have to fall back on software solutions.Just like with cars where there is no substitute for horsepower, there's no substitute for extra precision. Yes, there are known techniques for dealing with roundoff error, but these are complex and tricky and are for experts in this sort of thing. Adding more precision often "just works" for the rest.(There is a trick where you use two or more doubles to represent a number with more mantissa bits though and it is possible that with AVX, performance may be competitive with 80 bit floats, but vectorising that code manually is more work.)I didn't know about this. Is there an article on how it works?
Sep 18 2022
Enzo Ferrari once said: "The secret to better performance is more horsepower." A movie line: "Turbos are for wussies. This car has cubic inches."
Sep 18 2022
On Sunday, 18 September 2022 at 20:33:03 UTC, Walter Bright wrote:I didn't know about this. Is there an article on how it works?Search for PowerPC DoubleDouble
Sep 18 2022
On 9/18/2022 3:34 PM, Nicholas Wilson wrote:On Sunday, 18 September 2022 at 20:33:03 UTC, Walter Bright wrote:Yes, thank you. Turned up lots of articles.I didn't know about this. Is there an article on how it works?Search for PowerPC DoubleDouble
Sep 18 2022
On Sunday, 18 September 2022 at 20:33:03 UTC, Walter Bright wrote:Just like with cars where there is no substitute for horsepower, there's no substitute for extra precision.Yes there is. Use an algorithm with better convergence properties or that is more numerically stable. If you have a problem with precision, you have other problems. You should fix the other problems first.Yes, there are known techniques for dealing with roundoff error,The cases when roundoff is a problem is usually one of: * catastrophic loss of precision from (something like) finite difference derivatives (algorithmic fix: use dual numbers aka automatic differentiation), * massively different scales of the data you are working with. Your problem is poorly conditioned anyway, and you should try to separate the scales of your problem. * you are doing _so_ many operations that (unacceptable) drift occurs, in which case why are you doing so many ops? Usually its from something like an alternating series summation with terrible convergence. Algorithmic fix, fix your convergence properties.but these are complex and tricky and are for experts in this sort of thing.Libraries are a thing, mir for example has many solutions to these kinds of problems. The only expertise required is to recognise you have a problem that would be fixed by one of them.Adding more precision often "just works" for the rest.it is a bandaid fix that doesn't fix the root cause of your problem.
Sep 18 2022
On 19.09.22 01:01, Nicholas Wilson wrote:On Sunday, 18 September 2022 at 20:33:03 UTC, Walter Bright wrote:For my project the problem was specifically precision. I needed each pixel to have different coordinates even on really high zoom levels into the fractal. One nice thing about double-double was that if I centered the image directly on a number that is representable as a double, the maximum possible zoom level was increased massively. :)Just like with cars where there is no substitute for horsepower, there's no substitute for extra precision.Yes there is. Use an algorithm with better convergence properties or that is more numerically stable. If you have a problem with precision, you have other problems. You should fix the other problems first. ...
Sep 18 2022
On Sunday, 18 September 2022 at 23:18:06 UTC, Timon Gehr wrote:For my project the problem was specifically precision. I needed each pixel to have different coordinates even on really high zoom levels into the fractal. One nice thing about double-double was that if I centered the image directly on a number that is representable as a double, the maximum possible zoom level was increased massively. :)Right and that is well beyond the capability of x86-fp80, which was my original point. I think it makes sense to support real for PPC DoubleDouble, or IEEE quad. I don't think it does for x86-fp80.
Sep 18 2022
On 19.09.22 01:51, Nicholas Wilson wrote:On Sunday, 18 September 2022 at 23:18:06 UTC, Timon Gehr wrote:Well, I used adaptive precision, float/double/extended/double-double, whatever was needed for the current zoom level. Performance degraded at every step, while precision increased. There was a clear sweet spot where extended precision was the best option. Of course, as I said, nowadays with AVX and beyond, as well as powerful GPUs, maybe the trade-offs would indeed be a bit different. The support for fp80 is really nice even just for legacy reasons though, it allows porting code that uses the x87 and get consistent results, and it allows easy benchmarking to show that some other solution actually beats it on the given hardware. Most backends have to support it anyway for C long double on e.g. linux.For my project the problem was specifically precision. I needed each pixel to have different coordinates even on really high zoom levels into the fractal. One nice thing about double-double was that if I centered the image directly on a number that is representable as a double, the maximum possible zoom level was increased massively. :)Right and that is well beyond the capability of x86-fp80, which was my original point. I think it makes sense to support real for PPC DoubleDouble, or IEEE quad. I don't think it does for x86-fp80.
Sep 18 2022
On 18.09.22 22:33, Walter Bright wrote:I picked it up back in high school for a CPU-based fractal rendering project using vectorization, multithreading and some clever algorithms for avoiding computations (I should port it to D and publish it, a lot of it is Intel-style x86 inline assembly.) Unfortunately I don't recall what are all the online resources I found. I only needed addition and multiplication. Addition is rather straightforward, but multiplication required splitting the mantissa with Dekker's trick. I think this is the original paper (also crediting several others with similar ideas, e.g., Kahan summation is in Phobos. The multi-double data types are basically a generalization of that idea to other operations): https://csclub.uwaterloo.ca/~pbarfuss/dekker1971.pdf This seems to be a more recent account, maybe it is easier to read: https://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf I also found this Julia library: https://github.com/JuliaMath/DoubleFloats.jl I used the search terms "dekker double-double floating point", there might be even better articles out there. (This is an example of an application where extending precision implicitly for some subset of calculations can give you worse overall results.)(There is a trick where you use two or more doubles to represent a number with more mantissa bits though and it is possible that with AVX, performance may be competitive with 80 bit floats, but vectorising that code manually is more work.)I didn't know about this. Is there an article on how it works?
Sep 18 2022
On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.std.json
Sep 18 2022