Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent with
how 'invariant' and 'synchronized' are specified. They imply
class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public interface,
but it neither locks on c, nor runs the invariant checks. I
personally have no idea how to fix that sensibly except by
ditching class invariant/synchronized entirely.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 19:03:00 UTC, Walter Bright wrote: $0. true
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote:
https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/
'enum { Yes, No }; is just an automatic “no hire” decision'
'No hire' for language designers who design sum types to be
implicitly enumerated and convertible to integers and booleans?
Re: implicit-context v0.0.1
On Saturday, 30 September 2023 at 12:40:29 UTC, Guillaume Piolat wrote: When is it useful? You can use it to troll Jonathan Blow.
Re: Evolving the D Language
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
I don't remember people from outside the community being
impressed by alias this.
We have the right to backtrack on bad ideas instead of keeping
them forever.
I don't know why anybody should be impressed, but Zig and Jai,
the two closest competitors of D, both have a generalized version
of 'alias this' ('usingnamespace' and 'using', respectively).
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote: ``` value.type = STRING; ``` IRL people would use namespacing prefixes or actual namespaces anyway, so your example would look more like ``` value.type = VALUE_TYPE_STRING; ```
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 22:46:51 UTC, Ali Çehreli wrote:
https://forum.dlang.org/thread/qwixdanceeupdefyq...@forum.dlang.org
I still agree with myself :) in that discussion here:
https://forum.dlang.org/post/tlqcjq$usk$1...@digitalmars.com
BTW, check out another case of D violating the "if in an invalid
state, die" precept. The following code not only runs the
upstream destructor (which depends on successful completion of
the downstream one), but does that in an infinite loop:
struct TransactionFactory
{
Transaction spawnTransaction()
{
return Transaction(0);
}
// depends on all Transactions having been destroyed
~this()
{
assert(Transaction.count == 0);
}
}
struct Transaction
{
static int count;
// the usual "fake nullary constructor" fiddlesticks
this() @disable;
this(int dummy)
{
count++;
}
~this()
{
assert(false); // a failure that leaves the system in an
invalid state
count--;
}
}
void main()
{
TransactionFactory tf;
Transaction t = tf.spawnTransaction;
}
Re: Binary Literals Not Going Anywhere
On Monday, 26 September 2022 at 04:40:02 UTC, Mike Parker wrote: You may have seen [the long discussion about the deprecation of binary literals(https://forum.dlang.org/thread/vphguaninxedxopjk...@forum.dlang.org). A few hours ago, Walter and I recorded a second conversation for our YouTube channel. Before we got started, I asked him about the binary literal situation. He confirmed that they will not be deprecated. If you're using them today, you can keep using them tomorrow. Please do not take the backlash against the removal of binary literals as general aversion to breaking changes/deprecations. D has plenty to remove/deprecate (and it is NOT `alias this`, unless that is replaced with a more general mechanism, such as `using` in Jai).
Re: Giving up
On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote: On 8/5/2022 9:43 AM, Max Samukha wrote: Both "123." and "123.E123" is valid C. For some reason, D only copied the former. It's to support UFCS (Universal Function Call Syntax). UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.) nd, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero? We've got the right choice here, but it's definitely a judgement call. No objections to this.
Re: Giving up
On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer wrote: On 8/5/22 11:36 AM, Rumbu wrote: float z = 85886696878585969769557975866955695.E0; //integer overflow, I don't see any int That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`? -Steve Both "123." and "123.E123" is valid C. For some reason, D only copied the former.
Re: From the D Blog: Driving with D
On Tuesday, 8 June 2021 at 11:35:39 UTC, Iain Buclaw wrote: Testing backports of both now ([here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935) and [here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964)). Thanks!
Re: From the D Blog: Driving with D
On Monday, 7 June 2021 at 10:38:08 UTC, Max Samukha wrote:
Would be great if you did. Not a blocker, though.
However, this is a major pain:
```d
struct FP {
}
alias parse = () {
FP[] parts;
parts ~= FP();
return parts;
};
immutable s = parse();
extern(C) int main() {
return 0;
}
```
avr-gdc -fno-druntime ctfe.d
ctfe.d:3:1: error: 'object.TypeInfo' cannot be used with
'-fno-rtti'
3 | struct FP {
| ^
ctfe.d:3:1: error: 'object.TypeInfo' could not be found, but is
implicitly used
3 | struct FP {
| ^
d21: internal compiler error: Segmentation fault
0x178ae29 internal_error(char const*, ...)
Re: From the D Blog: Driving with D
On Sunday, 6 June 2021 at 22:39:34 UTC, Johan Engelen wrote: it's fun Hell Yeah! )
Re: From the D Blog: Driving with D
On Sunday, 6 June 2021 at 21:18:01 UTC, Iain Buclaw wrote: That sounds a lot like this issue: https://issues.dlang.org/show_bug.cgi?id=17857 Most certainly. Can backport that for GCC-11. Would be great if you did. Not a blocker, though.
Re: From the D Blog: Driving with D
On Sunday, 6 June 2021 at 18:57:06 UTC, Max Samukha wrote:
2) 'align' is mishandled
GCC's bugzilla won't let me register.
align(4)
struct S {
ubyte[4] bytes;
}
static assert (S.alignof == 4); // fail, S.alignof == 1
It's not specific to AVR. Worked around by placing 'align' inside
the struct.
Re: From the D Blog: Driving with D
On Friday, 4 June 2021 at 21:47:21 UTC, Iain Buclaw wrote: You should have better luck using gdc on avr. https://explore.dgnu.org/z/bos5ee Trying that, thank you. For now, two issues with GDC 11, which I hope to work around: 1) compiler complains about typeinfos of structs used in CTFE only, 2) 'align' is mishandled
Re: From the D Blog: Driving with D
On Friday, 4 June 2021 at 15:48:50 UTC, rikki cattermole wrote:
Does this form of foreach work?
foreach(i; 0 .. 10)
That does work.
This doesn't:
ubyte[] slice;
foreach (ubyte i; slice) {
}
Invalid bitcast
%17 = bitcast i16 %15 to i32
I guess the cause is the same - slice.length.sizeof == 4, while
slice.sizeof == 4, slice.ptr.sizeof == 2, and size_t.sizeof == 2.
Re: From the D Blog: Driving with D
On Tuesday, 1 June 2021 at 11:57:34 UTC, Mike Parker wrote: Dylan Graham writes about his experience using D in a microcontroller project and why he chose it. Does anyone know of any similar projects using D? I don't. This may well be the first time it's been employed in this specific manner. The blog: https://dlang.org/blog/2021/06/01/driving-with-d/ Reddit: https://www.reddit.com/r/programming/comments/nps6k5/driving_with_dlang/ FWIW, I tried D in a simple project using an atmega32a. It almost worked (thanks to Webfreak and LDC people), but there were a couple of issues: 1. No support for ISRs. I had to implement thunks in C calling D. 2. No slices, because 'length' is typed as 32-bit. Worked around by accessing the array's elements via .ptr. 3. No foreach (as a consequence of 2, I guess) 4. Integer promotion errors/warnings are very annoying when the primary integer type is byte. 5. A memory corruption bug (probably due to clobbered registers/corrupted stack/a stupid mistake of mine), which made me switch back to C++ for now.
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ "The destructors of all stack-allocated structs in a given scope are invoked when the scope exits." Please add a note that temporaries are scoped to the full expression, not the block.
Re: Interesting work on packing tuple layout
On Monday, 15 June 2020 at 14:55:37 UTC, Andrej Mitrovic wrote: On Monday, 15 June 2020 at 14:18:38 UTC, Timon Gehr wrote: Apparently, it has been fixed in 2.092. Nice! Oh wow that's fantastic. Does anyone know which changeset / PR fixed it? The person who fixed that must be commended.
Re: Interesting work on packing tuple layout
On Monday, 15 June 2020 at 13:57:01 UTC, Max Samukha wrote:
void main() {
Tuple!(byte, int, short) t;
writeln(t[0]);
}
test.d(57,23): Error: need `this` for `__value_field_2` of
type `byte`
It should work. This works:
void main() {
Tuple!(byte, int, short) t;
t[0] = 0;
t[1] = 2;
t[2] = 3;
auto a0 = t[0];
auto a1 = t[1];
}
}
I cannot reproduce the error. writeln(t[0]) works here:
https://run.dlang.io/is/kz6lFc
Re: Interesting work on packing tuple layout
On Monday, 15 June 2020 at 13:50:07 UTC, Andrej Mitrovic wrote:
typeof(t[0]) works fine, but reading or assigning to such a
field will not work. For example:
void main() {
Tuple!(byte, int, short) t;
writeln(t[0]);
}
test.d(57,23): Error: need `this` for `__value_field_2` of
type `byte`
It should work. This works:
void main() {
Tuple!(byte, int, short) t;
t[0] = 0;
t[1] = 2;
t[2] = 3;
auto a0 = t[0];
auto a1 = t[1];
}
}
Re: Interesting work on packing tuple layout
On Sunday, 14 June 2020 at 23:30:03 UTC, Andrei Alexandrescu
wrote:
It's really easy if members in the layout are given internal
names that include information about the original index.
You can construct a list of member aliases in the original order
and then 'alias this' that:
import std.meta;
struct Tuple(A...) {
alias Reordered = AliasSeq!(A[1], A[2], A[0]);
Reordered value;
alias reordered = AliasSeq!(typeof(this).tupleof);
alias original = AliasSeq!(reordered[2], reordered[0],
reordered[1]);
alias original this;
}
void main() {
Tuple!(byte, int, short) t;
static assert(is(typeof(t.tupleof) == AliasSeq!(int, short,
byte)));
static assert(is(typeof(t[0]) == byte));
static assert(is(typeof(t[1]) == int));
static assert(is(typeof(t[2]) == short));
}
