(This is my second attempt, the forums were down the first time…
:-( )
On Wednesday, 4 January 2023 at 02:54:51 UTC, Hipreme wrote:
Hello D Game Developers. As you guys know, I have been
developing a cross platform game engine for some years right
now. I'm close to release version 1.0.
On Saturday, 23 July 2022 at 08:32:12 UTC, Ola Fosheim Grøstad
wrote:
Also `char*` can't work as char cannot contain pointers. I
guess you would need to use `void*`.
Well, that is wrong for the standard collection where the typing
is dynamic (based on allocation not on type system). Then any
On Saturday, 23 July 2022 at 00:55:14 UTC, Steven Schveighoffer
wrote:
Probably. Though like I said, I doubt it matters. Maybe someone
with more type theory or GC knowledge knows whether it should
be OK or not.
Has nothing to do with type theory, only about GC implementation.
But his object
On Thursday, 21 July 2022 at 17:58:17 UTC, Johan wrote:
Godbolt now shows optimization pipeline steps for LDC, giving
great insight into the LLVM optimization process, including
Thanks for pointing this out, this was fun!
On Tuesday, 19 July 2022 at 15:30:30 UTC, Bienlein wrote:
If the destination of a carrier was set to null, it implied
that the destination was currently undefined. Then the robot
brought the carrier to some rack where it was put aside for a
while till the planning system had created a new
On Tuesday, 19 July 2022 at 09:55:52 UTC, Guillaume Piolat wrote:
I put tags in comments, to text search later.
Usually:
```
// TODO: actually blocks a release
```
Yes, this form is also recognized by some editors, might even
compile a todo-list in the IDE interface for you (with no
On Tuesday, 19 July 2022 at 10:29:40 UTC, Antonio wrote:
NULL is not the same that UNDEFINED
The distintion is really important: NULL is a valid value
(i.e.: The person phonenumber is NULL in database)... Of
course, you can represent this concept natively in you language
(Nullable,
On Monday, 18 July 2022 at 17:20:04 UTC, Kagamin wrote:
Difference between null and empty is useless.
Not really. `null` typically means that the value is missing,
irrelevant and not usable, which is quite different from having
"" as a usable value.
On Wednesday, 6 July 2022 at 21:30:44 UTC, Dukc wrote:
And I think there is still pretty much value in handling UTF-16
strings because that's what many other languages use. With the
current vision, Phobos V2 won't handle UTF16 in place. We'll
have to convert it to UTF8 before manipulation,
On Tuesday, 5 July 2022 at 11:49:20 UTC, ryuukk_ wrote:
I am sad that no word on the Allocator API, moving forward i
personally think APIs that use memory should be required to ask
for an Allocator and do their allocation using it, and only it
A default GCAllocator could be used if none
On Monday, 4 July 2022 at 16:12:35 UTC, rikki cattermole wrote:
https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt
Argh, linking to large files...
My implementation passes this :3
It should be complete test cases.
Well, you also have to test for the cases that should not
On Sunday, 3 July 2022 at 21:06:40 UTC, rikki cattermole wrote:
We have a perfectly good Unicode handling library already.
(Okay, little out of date and doesn't handle Turkic stuff, but
fixable).
The standard one is called ICU.
Yes, that is a common one that is maintained, but maybe there
On Sunday, 3 July 2022 at 20:28:18 UTC, rikki cattermole wrote:
We only support UTF-16/UTF-32 for the target endian.
Text input comes from many sources, stdin, files and say the
windowing system are three common sources that do not make any
such guarantees.
Well, then the application author
On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote:
It is required for string equivalent comparisons (which is what
you should be doing in a LOT more cases! Anything user provided
when compared should be normalized first.
Well, I think it is reasonable for a protocol to require
On Sunday, 3 July 2022 at 18:33:29 UTC, rikki cattermole wrote:
On 04/07/2022 6:10 AM, Ola Fosheim Grøstad wrote:
People who are willing to use 4 bytes per code point are
probably using third party C-libraries that have their own
representation, so you have to convert anyway?
If you use
On Sunday, 3 July 2022 at 17:27:43 UTC, rikki cattermole wrote:
That's going to bite us big time when it comes to Unicode
handling which wants to work with dstring's.
You can just use ints… It is better to do something commonly used
well, than have features that not enough people use to get
On Sunday, 3 July 2022 at 11:39:45 UTC, Mike Parker wrote:
Language evolution doesn't really mean much until we get all of
this sorted.
Good point.
That's right. But Walter wants to minimize its use in Phobos
v2, and there's a strong desire to have a pay-as-you-go
DRuntime. I'm not the
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
Feedback is welcome.
Thank you for putting this in clear terms. I miss an overarching
«primary use scenarios» to guide further language evolution. How
do you know if new language features are good or bad if you have
no scenarios to
On Saturday, 2 July 2022 at 09:42:17 UTC, Loara wrote:
But you first said "The compiler should deduce if a `scope`
pointer points to heap allocated data or not" and when someone
tells you this should happen only for not `scope` pointers you
say "But the compiler doesn't do that".
This
On Thursday, 30 June 2022 at 19:56:38 UTC, Loara wrote:
The deduction can happen even if you don't use `scope`
attribute.
I don't understand what you mean, it could, but it doesn't. And
if it did then you would not need `scope`…
When you use `scope` attribute you're saying to compiler "You
On Wednesday, 29 June 2022 at 05:51:26 UTC, bauss wrote:
Not necessarily, especially if the fields aren't value types.
You can have stack allocated "objects" with pointers to heap
allocated memory (heap allocated "objects".)
Those are not fields, those are separate objects… The compiler
On Tuesday, 28 June 2022 at 21:40:44 UTC, Loara wrote:
When `connect()` returns may happen that `b` is destroyed but
`a` not, so `a.next` contains a dangling pointer that
Not when connect returns, but the scope that connect was called
from. Still, this can be deduced, you just have to give
On Saturday, 25 June 2022 at 14:18:10 UTC, rempas wrote:
In that example, the first comparison will execute the second
branch and for the second comparison,
it will execute the first branch. Of course, this trait doesn't
exist I used an example to show what I want
to do. Any ideas?
I guess
On Friday, 24 June 2022 at 17:53:07 UTC, Loara wrote:
Why you should use `scope` here?
I probably shouldn't. That is why I asked in the «learn» forum…
A `scope` pointer variable may refer to a stack allocated
object that may be destroyed once the function returns.
The objects are in the
On Friday, 24 June 2022 at 09:08:25 UTC, Dukc wrote:
On Friday, 24 June 2022 at 05:11:13 UTC, Ola Fosheim Grøstad
wrote:
No, the lifetime is the same if there is no destructor. Being
counter intuitive is poor usability.
It depends on whether you expect the rules to be smart or
simple
On Friday, 24 June 2022 at 03:03:52 UTC, Paul Backus wrote:
On Thursday, 23 June 2022 at 21:34:27 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:
It's a weird rule for sure.
Another slightly annoying thing is that it cares about
destruction order
On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:
It's a weird rule for sure.
Another slightly annoying thing is that it cares about
destruction order when there are no destructors.
If there are no destructors the lifetime ought to be considered
the same for variables in the same
On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:
It means "may be returned or copied to the first parameter"
(https://dlang.org/spec/function.html#param-storage). You
cannot escape via other parameters. It's a weird rule for sure.
Too complicated for what it does… Maybe @trusted
On Thursday, 23 June 2022 at 19:38:12 UTC, ag0aep6g wrote:
```d
void connect(ref scope node a, return scope node* b)
```
Thanks, so the `return scope` means «allow escape», not
necessarily return?
But that only works for this very special case. It falls apart
when you try to add a third
How am I supposed to write this:
```d
import std;
@safe:
struct node {
node* next;
}
auto connect(scope node* a, scope node* b)
{
a.next = b;
}
void main()
{
node x;
node y;
connect(,);
}
```
Error: scope variable `b` assigned to non-scope `(*a).next`
On Thursday, 23 June 2022 at 06:52:48 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 June 2022 at 06:36:23 UTC, Ola Fosheim Grøstad
wrote:
Track the object instead and don’t change the type of the
pointer to scope.
I guess this is flow typing too, but it is less intrusive to
say
On Thursday, 23 June 2022 at 06:36:23 UTC, Ola Fosheim Grøstad
wrote:
Track the object instead and don’t change the type of the
pointer to scope.
I guess this is flow typing too, but it is less intrusive to say
that the object is either of type «scope» or type «heap» and that
regular
On Thursday, 23 June 2022 at 00:45:09 UTC, Steven Schveighoffer
wrote:
I think this is the better option. Either that, or that when it
returns `p` that trumps any possible `scope` inference.
Imagine you have a function like this:
```d
int foo()
{
int x = 0;
x = long.max;
x = 2;
On Wednesday, 22 June 2022 at 21:20:33 UTC, Steven Schveighoffer
wrote:
Full flow analysis will be defeatable by more complex
situations:
```d
int *p = null;
if(alwaysEvaluateToFalse()) p =
else p = new int(5);
return p;
```
That would take a lot of effort just to prove it shouldn't be
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer
wrote:
The part about `scope` being shallow. This is a problem.
One thing that will be confusing to most users is that it appears
to be using "taint" rather than proper flow analysis on the
pointed-to-object?
```d
int*
On Wednesday, 22 June 2022 at 19:09:28 UTC, Dukc wrote:
On Tuesday, 21 June 2022 at 15:05:46 UTC, Mike Parker wrote:
The blog:
https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a-modern-system-programming-language-pt-1/
Now on 26. place at Hacker News.
This was a nice
On Friday, 17 June 2022 at 14:14:57 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 17 June 2022 at 13:58:15 UTC, Soham Mukherjee wrote:
Is there any better way to achieve encapsulation in Python?
Please rectify my code if possible.
One convention is to use "self._fieldname" for
On Friday, 17 June 2022 at 13:58:15 UTC, Soham Mukherjee wrote:
Is there any better way to achieve encapsulation in Python?
Please rectify my code if possible.
One convention is to use "self._fieldname" for protected and
"self.__fieldname" for private class attributes.
On Monday, 13 June 2022 at 14:03:13 UTC, Steven Schveighoffer
wrote:
Merge sort only works if it's easy to manipulate the structure,
like a linked-list, or to build a new structure, like if you
don't care about allocating a new array every iteration.
The easiest option is to have two buffers
On Monday, 13 June 2022 at 13:22:52 UTC, Steven Schveighoffer
wrote:
I would think sort(joiner([arr1, arr2, arr3])) should work, but
it's not a random access range.
Yes, I got the error «must satisfy the following constraint:
isRandomAccessRange!Range`».
It would be relatively easy to make
On Monday, 13 June 2022 at 09:08:40 UTC, Salih Dincer wrote:
On Monday, 13 June 2022 at 08:51:03 UTC, Ola Fosheim Grøstad
wrote:
But it would be much more useful in practice if "chain" was a
dynamic array.
Already so:
I meant something like: chain = [arr1, arr2, …, arrN]
I
Is there a dynamic chain primitive, so that you can add to the
chain at runtime?
Context: the following example on the front page is interesting.
```d
void main()
{
int[] arr1 = [4, 9, 7];
int[] arr2 = [5, 2, 1, 10];
int[] arr3 = [6, 8, 3];
sort(chain(arr1, arr2, arr3));
On Monday, 6 June 2022 at 18:08:17 UTC, Ola Fosheim Grøstad wrote:
There is no reason for D to undercut users of @safe code.
(Wrong usage of the term «undercut», but you get the idea…)
On Monday, 6 June 2022 at 17:52:12 UTC, Steven Schveighoffer
wrote:
Then that's part of the algorithm. You can use an Exception,
and then handle the exception by calling the real sort. If in
the future, you decide that it can properly sort with that
improvement, you remove the Exception.
On Monday, 6 June 2022 at 16:15:19 UTC, Ola Fosheim Grøstad wrote:
On Monday, 6 June 2022 at 15:54:16 UTC, Steven Schveighoffer
wrote:
If it's an expected part of the sorting algorithm that it *may
fail to sort*, then that's not an Error, that's an Exception.
No, it is not expected. Let me
On Monday, 6 June 2022 at 15:54:16 UTC, Steven Schveighoffer
wrote:
If it's an expected part of the sorting algorithm that it *may
fail to sort*, then that's not an Error, that's an Exception.
No, it is not expected. Let me rewrite my answer to Sebastiaan to
fit with the sort scenario:
For
On Monday, 6 June 2022 at 11:23:44 UTC, Daniel N wrote:
So Object-C can import C, but *C* cannot import *C*.
Objective-C is a proper superset of C AFAIK.
On Monday, 6 June 2022 at 11:02:32 UTC, Ola Fosheim Grøstad wrote:
Yes, Objective-C has added modules to C since forever… Just
rename your .c file to .m
I guess that would be the first.
Or maybe not… you still use .h, so it depends on the
implementation. Pointless discussion really.
On Monday, 6 June 2022 at 05:49:55 UTC, Paulo Pinto wrote:
https://clang.llvm.org/docs/Modules.html
And I am out of this thread.
Yes, Objective-C has added modules to C since forever… Just
rename your .c file to .m
I guess that would be the first.
On Monday, 6 June 2022 at 01:05:38 UTC, zjh wrote:
On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:
Because it's fun to be first!
Yes, `'d'` is always independent.
[C++'s
moudle](https://www.oschina.net/news/198583/c-plus-plus-23-to-introduce-module-support)
`D`, hurry up and get
On Monday, 6 June 2022 at 06:56:46 UTC, Ola Fosheim Grøstad wrote:
On Monday, 6 June 2022 at 06:14:59 UTC, Sebastiaan Koppe wrote:
Those are not places where you would put an assert.
The only place to put an assert is when *you* know there is no
recovery.
No, asserts are orthogonal
On Monday, 6 June 2022 at 06:14:59 UTC, Sebastiaan Koppe wrote:
Those are not places where you would put an assert.
The only place to put an assert is when *you* know there is no
recovery.
No, asserts are orthogonal to recovery. They just specify the
assumed constraints in the
On Monday, 6 June 2022 at 04:59:05 UTC, Ola Fosheim Grøstad wrote:
An assert only says that the logic of that particular function
is not meeting the SPEC.
Actually, the proper semantics are weaker than that, the spec
would be preconditions and post conditions. Asserts are actually
just steps
On Sunday, 5 June 2022 at 23:57:19 UTC, Steven Schveighoffer
wrote:
It basically says "If this condition is false, this entire
program is invalid, and I don't know how to continue from here."
No, it says: this function failed to uphold this invariant. You
can perfectly well recover if you
On Sunday, 5 June 2022 at 21:08:11 UTC, Steven Schveighoffer
wrote:
Just FYI, this is a *different discussion* from whether Errors
should be recoverable.
Ok, but do you a difference between being recoverable anywhere
and being recoverable at the exit-point of an execution unit like
an
On Sunday, 5 June 2022 at 14:24:39 UTC, Ali Çehreli wrote:
void add(int i) {// <-- Both arrays always same size
a ~= i;
b ~= i * 10;
}
void foo() {
assert(a.length == b.length); // <-- Invariant check
// ...
}
Maybe it would help if we can agree that this assert
Ok, so I am a bit confused about what is Error and what is not…
According to core.exception there is wide array of runtime Errors:
```
RangeError
ArrayIndexError
ArraySliceError
AssertError
FinalizeError
OutOfMemoryError
InvalidMemoryOperationError
ForkError
SwitchError
```
I am not sure that
On Sunday, 5 June 2022 at 11:13:48 UTC, Adam D Ruppe wrote:
On Sunday, 5 June 2022 at 10:38:44 UTC, Ola Fosheim Grøstad
wrote:
That is a workaround that makes other languages more
attractive.
It is what a lot of real world things do since it provides
additional layers of protection while
On Sunday, 5 June 2022 at 00:18:43 UTC, Adam Ruppe wrote:
Run it in a separate process with minimum shared memory.
That is a workaround that makes other languages more attractive.
It does not work when I want to have 1000+ actors in my game
server (which at this point most likely will be
On Sunday, 5 June 2022 at 07:28:52 UTC, Sebastiaan Koppe wrote:
Go has panic. Other languages have similar constructs.
And recover.
So D will never be able to provide actors and provide fault
tolerance.
I guess it depends on the programmer.
But it isn’t if you cannot prevent Error from
On Sunday, 5 June 2022 at 07:21:18 UTC, Ola Fosheim Grøstad wrote:
You can make the same argument for an interpreter: if an assert
fails in the intrrpreter code then that could be a fault in the
interpreter therefore you should shut down all programs being
run by that interpreter.
Typo
On Sunday, 5 June 2022 at 03:43:16 UTC, Paul Backus wrote:
See here:
https://bloomberg.github.io/bde-resources/pdfs/Contracts_Undefined_Behavior_and_Defensive_Programming.pdf
Not all software is banking applications. If an assert fails that
means that the program logic is wrong, not that the
On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
Errors are thrown when the program is discovered to be in an
invalid state. We don't know what happened and when. For
example, we don't know whether the memory has been overwritten
by some rogue code.
That is not very probable in
On Saturday, 4 June 2022 at 22:01:57 UTC, Steven Schveighoffer
wrote:
You shouldn't retry on Error, and you shouldn't actually have
any Errors thrown.
So what do you have to do to avoid having Errors thrown? How do
you make your task/handler fault tolerant in 100% @safe code?
On Saturday, 4 June 2022 at 18:32:48 UTC, Sebastiaan Koppe wrote:
Most wont throw a Error though. And typical services have
canary releases and rollback.
So you just fix it, which you have to do anyway.
I take it you mean manual rollback, but the key issue is that you
want to retry on
On Saturday, 4 June 2022 at 16:55:50 UTC, Sebastiaan Koppe wrote:
The reasoning is simple: Error + nothrow will sidestep any RAII
you may have. Since you cannot know what potentially wasn't
destructed, the only safe course of action is to abandon ship.
Why can't Error unwind the stack
On Saturday, 4 June 2022 at 01:17:28 UTC, Steven Schveighoffer
wrote:
I've thought in the past that throwing an error really should
not throw, but log the error (including the call stack), and
then exit without even attempting to unwind the stack. But code
at least expects an attempt to throw
On Wednesday, 18 May 2022 at 10:53:03 UTC, forkit wrote:
Here is a very interesting article that researches this subject.
Yeah, he got it right. It is syntax sugar that makes verbose C++
code easier to read. Use struct for internal objects and tuple
like usage and class for major objects in
On Monday, 16 May 2022 at 15:18:11 UTC, Kevin Bailey wrote:
I would say that assignment isn't any more or less of an issue,
as long as you pass by reference:
What I mean is if you write your code for the superclass, and
later add a subclass with some invariants that depends on the
superclass
On Sunday, 15 May 2022 at 20:05:05 UTC, Kevin Bailey wrote:
I've been programming in C++ full time for 32 years, so I'm
familiar with slicing. It doesn't look to me like there's a
concern here.
Yes, slicing is not the issue. Slicing is a problem if you do
"assignments" through a reference
On Friday, 13 May 2022 at 04:39:46 UTC, Tejas wrote:
On Friday, 13 May 2022 at 04:19:26 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 13 May 2022 at 03:31:53 UTC, Ali Çehreli wrote:
On 5/12/22 18:56, forkit wrote:
> So...you want to do a talk that challenges D's complexity,
> by
getting
On Friday, 13 May 2022 at 03:31:53 UTC, Ali Çehreli wrote:
On 5/12/22 18:56, forkit wrote:
> So...you want to do a talk that challenges D's complexity, by
getting
> back to basics?
I wasn't thinking about challenging complexity but it gives me
ideas.
I am looking for concrete topics like
On Wednesday, 11 May 2022 at 10:01:18 UTC, Johan wrote:
Any function call (inside the loop) for which it cannot be
proven that it never modifies your memory variable will work.
That's why I'm pretty sure that mutex lock/unlock will work.
I think the common semantics ought to be that
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
What are you stuck at? What was the most difficult features to
understand? etc.
Also, if you intend to use the responses for planning purposes,
keep in mind that people who read the forums regularly are more
informed about
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
What are you stuck at? What was the most difficult features to
understand? etc.
No singular feature, but the overall cognitive load if you use
the language sporadic. Which could be most users that don't use
it for work or have it
On Tuesday, 10 May 2022 at 19:24:25 UTC, Andrea Fontana wrote:
Maybe bambinetto is more about immaturity. Bambinuccio is cute.
Bambinaccio is bad. Bambinone is big (an adult that behave like
a child). -ello doesn't sound good with bambino, but it's very
similar to -etto.
Good luck :)
On Tuesday, 10 May 2022 at 16:05:11 UTC, Andrea Fontana wrote:
Oh, italian is full of suffixes. -ello means a slightly
different thing. It's small but sounds like a bit pejorative.
Oh, and I loved the sound of it… suggests immaturity, perhaps?
(I love the -ello and -ella endings. «Bambinella»
On Tuesday, 10 May 2022 at 15:27:48 UTC, Andrea Fontana wrote:
Indeed the "-ino" suffix in "serverino" stands for "small" in
italian. :)
Bambino > bambinello? So, the embedded-version could be
«serverinello»? :O)
On Tuesday, 10 May 2022 at 15:00:06 UTC, Andrea Fontana wrote:
I work in the R and every single time I even have to write a
small api or a simple html interface to control some strange
machine I think "omg, I have to set nginx agaain".
Good point, there are more application areas than
On Tuesday, 10 May 2022 at 12:52:01 UTC, Andrea Fontana wrote:
I'm running a whole website in D using fastcgi and we have no
problem at all, it's blazing fast. But it's not so easy to
setup as serverino :)
Easy setup is probably the number one reason people land on a
specific web-tech, so it
On Tuesday, 10 May 2022 at 10:49:06 UTC, Andrea Fontana wrote:
And you can still handle 700k/views per hour with 20 workers!
Requests tend to come in bursts from the same client, thanks to
clunky javascript APIs and clutters of resources (and careless
web developers). For a typical D user
On Wednesday, 4 May 2022 at 10:15:18 UTC, bauss wrote:
It can be a bug __and__ an enhancement.
Alright, but we need a DIP to get the enhancement which can be
in. :-) I don't think anything will improve without one.
I would assume that C++ template resolution is O(N), so I am not
as
On Tuesday, 3 May 2022 at 15:41:08 UTC, Ali Çehreli wrote:
We also have NP-completeness.
Ok, so C++ has similar limitations when you have a template with
an unknown parameter in a function parameter, but is this because
it would be NPC? Also, do we know that it cannot be resolved for
the
On Tuesday, 3 May 2022 at 06:20:53 UTC, Elfstone wrote:
Yeah, I understand some cases are impossible, and to be
avoided. I believe your example is also impossible in C++, but
it's better the compiler do its job when it's totally possible
- needless to say, C++ compilers can deduce my _dot_.
On Monday, 14 February 2022 at 15:51:59 UTC, Kagamin wrote:
3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8 is 0xDB8C5218B9329CF8
This shortening was supposed to improve user experience.
Yes, I eventually noticed that the shortened fingerprints were
used, but only after posting the OP… It is natural
On Monday, 14 February 2022 at 18:12:25 UTC, Era Scarecrow wrote:
For Linux sources there's MD5 and SHA-1 hashes i believe. If
you have two or three hashes for comparison, the likelyhood of
someone changing something without those two changing seems
VRY low.
I usually grab the sources
On Wednesday, 9 February 2022 at 17:48:29 UTC, Guillaume Piolat
wrote:
There is also the Nim "discard" statement.
Just change the default to not allowing return values to be
discarded. When you really want to, do:
```
cast(void) function_with_return_value(…)
```
Or something like that.
On Wednesday, 9 February 2022 at 10:59:03 UTC, Dukc wrote:
You're implying that your opinion is rational and apolitical,
disagreeing with it is irrational politics.
I am implying that there are many symptoms of people not being
willing to champion the best possible design and instead have
On Tuesday, 8 February 2022 at 20:15:50 UTC, forkit wrote:
btw. the key is listed there - not sure what you mean.
I didn't see "3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8" on the
listing on the webpage https://dlang.org/gpg_keys.html
That pages is not similar to what I get with "--list-keys
On Tuesday, 8 February 2022 at 20:15:50 UTC, forkit wrote:
On what basis would you trust the key? Think about it ;-)
Oh well, seems like the keyring has nothing to do with trust.
This model with no certification authority is annoying. Now I
remember why I never bother with PGP.
I don't use GPG often, so I probably did something wrong, and
failed to get a trusted verification. I do like the idea that a
hacker cannot change the signature file if gaining access to the
web/file hosts, but how to verify it in secure way?
I did this:
```
/opt/local/bin/gpg --keyring
On Sunday, 6 February 2022 at 20:52:21 UTC, Paul Backus wrote:
If you intended to direct your messages at "the community" in
general, rather than at me specifically, you should have
started a new thread. As is, with these messages buried several
pages deep in a thread about a different topic,
On Sunday, 6 February 2022 at 19:14:50 UTC, Paul Backus wrote:
Let me rephrase: I do not understand why you feel the need to
direct these messages at me, personally.
I am sorry if you felt I was addressing you personally. That was
not intended, maybe bad phrasing on my part. (I tend to send
On Sunday, 6 February 2022 at 16:20:07 UTC, Paul Backus wrote:
I did not reply (and do not intend to reply) to any of the
numerous other statements you have made in your other replies
to this thread, since they are statements about the design of
the D language and the DIP process in general,
On Sunday, 6 February 2022 at 15:51:46 UTC, Paul Backus wrote:
If you're still confused *after* you've read the documentation,
feel free to come back and complain to me then.
What I stated has nothing to do with documentation. I think the
semantics are too important to be a "linter-feature".
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
To be honest, though, I can see where he's coming from. When
writing DIP 1038, I made a conscious effort to avoid using the
term "non-`@nodiscard`", due to the double negative. With a
positively-phrased name like `@mustUse`, that
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
@mustUse is a user-defined attribute, and the official style
guide says that names of UDAs
On Sunday, 6 February 2022 at 14:56:42 UTC, Paul Backus wrote:
If you strongly prefer the lower-case version, you can always
rename it in your own code:
import core.attribute: mustuse = mustUse;
This response is getting a bit longwinded, and I really want this
feature, but…
1.
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N wrote:
Guess I'm way too late, I just find it very strange you
settled on mixedCase, it's not used for anything else.
(nothrow @nogc). I also don't agree with the motivation
On Friday, 28 January 2022 at 13:27:33 UTC, WebFreak001 wrote:
If there are people that would get upset from removing it, it's
something that shouldn't be removed. (as there are people who
are still interested in the project and might still use it)
I hear what you are saying, but maybe there
1 - 100 of 2358 matches
Mail list logo
