Re: Crow programming language
On Thursday, 15 February 2024 at 23:46:10 UTC, andy wrote: Is it as simple as that? I'd have to cast away the `immutable` when adding a new interned string though. Is that still the correct way to do it? Oh no, you should never cast away immutable, that might lead to undefined behaviour (as immutable objects may be placed in ROM) Pure should not be able to read any global mutable data, either way… I declare a parameter `scope` whenever it's true — the memory isn't retained anywhere — even if I can't prove that to the compiler, so it needs to be trusted instead. This comes up a lot because `scope` only applies one level deep, so if I need a pointer to something `scope`, I'm forced to cast away the scopeness of the pointee. This happens if I need to put it in a `struct` since `struct`s can't contain `ref`s, only pointers. Oh, interesting. I’ve never had this exact issue
Re: Crow programming language
On Thursday, 15 February 2024 at 04:32:27 UTC, andy wrote:
* Having to write `@safe @nogc pure nothrow` all the time. It
needs a way to make that the default and mark specific things
as not-safe or not-pure.
You can make a scope with `nothrow`, `@nogc`, etc.:
```d
nothrow @nogc pure @safe{
void fn1(){}
void fn2(){}
void fn3(){}
}
```
A pattern matching syntax for D could make this prettier.
I think Walter has a draft DIP for "sumtype"s with pattern
matching.
I really wish this would be added soon.
One annoyance with pure code is having to pass `AllSymbols`,
the symbol (interned string) table, to any function that needs
to create a symbol or un-intern it. I think using this through
a global variable could be considered pure, since a caller to
`symbolOfString` can't tell whether the symbol has been added
or not, and the `stringOfSymbol` never changes. But I'm not
sure if that's actually safe or how to tell D to allow a global
variable in pure code.
If you make global variables `immutable`, you can access them in
`pure` functions.
`pure` functions are not really meant to access global mutable
data.
I often need to cast away `scope` using a function
`castNonScope`.
This feels like it needs a language intrinsic or at least a
standard
library function.
I think you're not meant to cast away `scope`?? `scope` is meant
to guarantee that a variable doesn't escape the given scope;
casting it away breaks that guarantee, so why use it? If you're
using it for memory allocation, be careful... it's not meant for
that.
Re: DMD Beta 2.105.0
On Monday, 17 July 2023 at 19:26:04 UTC, Witold Baryluk wrote: On Sunday, 16 July 2023 at 17:26:03 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.105.0 release, ♥ to the 34 contributors. Thanks for the beta Iain. Functions can no longer have enum storage class This looks like a breaking change that can affect people. There should be a deprecation (6-12 months) period to give people notice to fix their code, without immediately breaking code. https://github.com/dlang/dmd/pull/15405 and https://issues.dlang.org/show_bug.cgi?id=13063 show there was no discussion on deprecation, despite authors knowing that there is code in the wild using this. It does not affect me, but in light in recent discussions, it again gives a bad picture of D and maintainability of code developed in D. You’re correct about the deprecation cycle being wrong, but please remember that “enum” on a function is just a more confusing way of writing “auto”. Anyone using it *probably didn’t understand* what it did—nothing much.
Re: Evolving the D Language
On Sunday, 9 July 2023 at 18:51:01 UTC, IchorDev wrote: [...] I felt that I should also clarify that there are some features that *should* stay dead, for our benefit. I figured I'd name a few. 1. Bugs that some people treated like features. There's a few listed among D's deprecated features. 2. `body`—find-and-replace is enough to update it, and `body` shouldn't be a keyword. 3. C-style function pointers. They are absolutely horrid; so hard to read that it hurts. 4. Escape-string literals seem to have been designed to confuse people, much like 5. implicit string concatenation. 6. De-referencing arrays with `*`. 7. Comma expression results. Tuples & deconstruction instead would be nice! Most of these changes don't really prevent you from doing things you could previously do with the base language (like removing class `alias this`), they syntax clean-up that you can mostly update to with a rudimentary regex or a bit of manual error-pecking. P.S. "error-pecking" as in "build, try to fix any compiler errors, rinse, repeat".
Re: Evolving the D Language
On Friday, 7 July 2023 at 13:19:51 UTC, Nick Treleaven wrote: Changing the syntax just for an obsolete feature would send the wrong message. [...] cent and ucent are already an error as of 2.100. Were they even implemented? Clearly you're not looking at this the same way as me, [or Walter](https://github.com/dlang/dmd/pull/15393). Fixing old code isn't the only upside to resurrecting old features. First thing, I think all languages should support binary, octal, decimal and hexadecimal literals as a baseline. Octal is probably the least important of them, but can still be plenty useful in its own right. You technically don't need *any* numerical literals at all in D, you could make all of them with string-to-number templates. You could take such an approach to just about everything in D, actually! On the other hand, people working on low-level Linux code might be pretty appalled to find out that they can't simply use octal literals to represent file permissions in D. Second, I think re-examining and sometimes resurrecting features that were removed from D, no matter how long ago, is important. Think about it this way, the only reason D doesn't have octal literals right now is because when it did have octal literals the syntax was ambiguous. The solution at the time was removing them from the language, but had their syntax been modified at the time then they wouldn't have been ambiguous. Who says it's too late? There are a few D features that were poorly implemented (or not implemented at all), and then simply removed instead of being fully reconsidered. You might say that for many, they were indeed reconsidered, and then added to Phobos instead. Now some of these features pre-date BetterC, of course, but I am a regular BetterC user. A feature being moved to Phobos translates to "you don't get to use this in most of your code anymore" for me. I'm not a user of complex or imaginary types, but I don't see why they needed to be removed from D, were they a huge burden to maintain compared to being in Phobos? TL;DR I think we should be more lenient about leaving features in the language if they aren't in the way, and consider ways of modifying them rather than removing them from the language if they get in the way.
Re: Evolving the D Language
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote: As time moves on, the D language has to evolve as well. What do we do with obsolete and/or problem-causing, legacy features? Our answer was deprecation. The deprecation starts out as just a message, which can be disabled, or can be set to be errors. The deprecations could last for many years, then become errors, but with a "-revert" switch if one still wanted to use them. I thought that was a straightforward approach, giving people many years to modernize their code. I was wrong. I heard you. We're going to have to change course. [...] This is an interesting decision indeed. However, definitely I agree with Rikki that it should be opt-in, rather than opt-out. Your thoughts and advice are appreciated. Feel free to add this thread your wish lists on legacy feature resurrection that should have priority. Or if you've got a better idea, let us know! Hexstring literals, complex and imaginary floating point types & the corresponding literals, built-in 128-bit integer types, and octal literals, I think could all be added back to D without causing much detriment to D users who don't want to use them. For people who do use them, they're very useful to have. I'm not sure how open you are to tweaking legacy features slightly, but here are some suggestions in case that's on the table: 1. I think adapting `std.int128.Int128` to make `cent`/`ucent` functional for the sake of simpler BetterC code would be really lovely. Much nicer than having to create custom wrappers over `core.int128.Cent`... 2. Ideally octal literals would have a better syntax. (e.g. "0o123")
Re: A New Era for the D Community
On Wednesday, 5 July 2023 at 21:50:37 UTC, Andrew wrote: Why not just improve Phobos itself? Make PRs to add new modules to std.experimental, announce them here and elsewhere on the web, and get the community to support it. Earlier in this thread it was pointed out that it's too arbitrary whether new modules will get accepted into `std.experimental` or not, therefore a fork that's more open to community contributions (whether good or bad), would be of value. As it is, some of Phobos is really great, some of it could do with more nothrow/custom allocator alternatives or a nicer API that clashes with itself less often, and some of it is just horrid. P.S. Who chose this silly name "std.experimental"? It might as well be "std.nonstandard".
Re: A New Era for the D Community
On Saturday, 13 May 2023 at 15:58:12 UTC, ryuukk_ wrote: - better enums - tagged union - pattern matching - async - nullable - tuple/multiple return (deconstruction) - allocators (don't do them as classes/interface for the love of god) - implement GC as an allocator This is a nice list, however I'd like to point out that not all of these need to be language features. Nullable already exists in Phobos: https://dlang.org/library/std/typecons/nullable.html You might say it should be a language feature, but I nullable value-types are a bit weird—they can be a value that *isn't a value*. Pattern matching can be done in various ways, and the same to some extent with tuples. Perhaps a fork of Phobos that's more community-driven would be good for the language?
