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_.
Con
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 typ
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 pessimis
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 a
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 pitfalls
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 everythin
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 tem
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
> back
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 tha
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 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 y
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 t
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 properly
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 failur
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 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 100%
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 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: if an
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 pr
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 writ
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 stil
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 a
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 ou
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 Actor/T
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 know
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 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 implementation
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 to recove
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 i
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 rew
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.
That
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…)
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));
wri
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 don't use range
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 i
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 t
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 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 protected and
"sel
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(&x,&y);
}
```
Error: scope variable `b` assigned to non-scope `(*a).next`
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 nod
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 isn'
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 s
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 wh
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. Smart
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 cal
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 yo
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 the
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
knows
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 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 discuss
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 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, Optional,
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 produ
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 h
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 Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
I'm trying to find the rationale why GC pointers (should be
names managed pointers) are using the exact same type as any
other pointer.
I assume you mean a GC that scans (not ref counting). GC pointers
only need to be protected fro
On Saturday, 16 November 2019 at 09:21:41 UTC, René Heldmaier
wrote:
Do i have to list the authors of std.complex as authors of the
module?
Or should i list the authors in the commentary above the copied
functions?
I believe the correct answer would depend on your jurisdiction
(the country yo
One advantage of using abstract OO superclasses is that you can
implement a lot of functionality on the superclass and save
yourself some work when implementing concrete subclasses.
However, virtual functions can be slow. In Rust you can do the
same with "traits", but statically.
What is the
On Saturday, 23 November 2019 at 15:06:43 UTC, Adam D. Ruppe
wrote:
Is your worry in slowness of virtual functions or heap
allocation?
I'm trying to measure how well optimised naive and very generic
code is, basically an exploration of "expressiveness", "strong
typing support" and "effort" vs
On Saturday, 23 November 2019 at 15:09:44 UTC, Adam D. Ruppe
wrote:
On Saturday, 23 November 2019 at 13:17:49 UTC, mipri wrote:
template isNamed(alias T) {
enum isNamed = hasStaticMember!(T, "secretlyIsNamed");
}
this looks like a place to use a @Named uda!
@Named struct World {}
@N
On Tuesday, 3 December 2019 at 09:22:49 UTC, Jan Hönig wrote:
not evaluate into: 0.30004, like C++
but rather to: 0.2
You get the same in C++ with:
#include
int main()
{
printf("%.17f",double(0.1L + 0.2L));
}
On Tuesday, 3 December 2019 at 09:52:18 UTC, mipri wrote:
Most other languages give you the double result for very
reasonable historical reasons
Not only historical, it is also for numerical reasons. You can
get very unpredictable results if you do compares and compiletime
evalution is differ
When is there a noticable difference when using const values
instead of immutable values in a function body? And when should
immutable be used instead of const?
f(){
const x = g();
immutable y = g();
... do stuff with x and y …
}
I'm comparing D to C++ and I get the following mapping:
D
Also, in file scope, would C++:
constexpr auto constant = 3;
be the same as:
immutable constant = 3;
?
On Wednesday, 4 December 2019 at 22:29:13 UTC, kerdemdemir wrote:
Unfortunately I am not yet good with D to answer your question .
But Ali Çehreli made some comparesions with C++.
https://dconf.org/2013/talks/cehreli.pdf
And I think you will find the answers of your questions in it
also.
Thank
On Wednesday, 4 December 2019 at 22:43:35 UTC, Bastiaan Veelo
wrote:
There is a difference I guess if g() returns a reference type
and is an inout function. immutable y will only work if the
reference returned is immutable.
But not for values?
Const is a promise to the rest of the code that y
On Wednesday, 4 December 2019 at 22:51:01 UTC, Ola Fosheim
Grøstad wrote:
Is there a way to specify in generic code that you want the
best fit of a const/immutable reference depending on the return
type (but not a mutable one)?
I mean, if f() return mutable or const then it should be const,
b
On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven
Schveighoffer wrote:
void main()
{
foo!a(); // const(int)
foo!b(); // immutable(int)
foo!c(); // const(int)
}
Ok, so one has to use a wrapper and then "catch" the result with
auto?
auto x = foo!f();
I haven't used const much in the past because I got burned on
transitive const, so I managed to confuse myself. I am not
really interested in const/immutabel references here, but values.
Seems like there is no reason to ever use const values, except
when they contain a pointer to something non
I haven't used const much in the past because I got burned on
transitive const, so I managed to confuse myself. I am not
really interested in const/immutabel references here, only
values. Seems like there is no reason to ever use const values,
except when the value may contain a pointer to som
On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven
Schveighoffer wrote:
void foo(alias f)()
{
alias ConstType = const(typeof(f()));
pragma(msg, ConstType);
}
I expressed myself poorly, what I am interested in is this:
struct node1 {int value; const(node1)* next;}
struct node2 {int val
I also find the following behaviour a bit unclear:
struct node0 {int value; node0* next;}
struct node1 {int value; const(node1)* next;}
struct node2 {int value; immutable(node0)* next;}
T mk(T)(){
T tmp = {2019, null};
return tmp;
}
node1 mk_node1(){
node1 tmp = {2019, null};
re
On Thursday, 5 December 2019 at 10:41:24 UTC, Ola Fosheim Grøstad
wrote:
immutable x1 = mk!node1(); //succeeds?
immutable y1 = mk_node1(); //fails
Nevermind, seems like templated functions get stronger coercion,
like:
immutable y1 = cast(immutable)mk_node1();
(Also no need to exp
So basically, templated functions get flow-typing. I guess that
is a good reason to use templated functions more...
What is the downside? E.g.:
struct node {int value; node* next;}
node mk_node2()(){
node tmp = {2019, null};
return tmp;
}
node mk_node(){
node tmp = {2019, null};
On Thursday, 5 December 2019 at 12:00:23 UTC, Ola Fosheim Grøstad
wrote:
So basically, templated functions get flow-typing.
But it is not reliable :-(
struct node {int value; node* next;}
node n0 = {1,null};
node mk_node1()(node* n){
node tmp = {2019, n};
return tmp;
}
node mk_node
On Tuesday, 14 January 2020 at 12:05:01 UTC, John Burton wrote:
After years of C++ I have become paranoid about any casting of
pointers being undefined behavior due to aliasing so want to
see if :-
FWIW, this is safe and portable in C++20:
https://en.cppreference.com/w/cpp/numeric/bit_cast
On Tuesday, 15 September 2020 at 01:49:13 UTC, James Blachly
wrote:
I wish to write a function including ∂x and ∂y (these are
You can use the greek letter delta instead:
δ
On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote:
Are effectively the same thing, whether it's implemented that
way or not. So why on earth would a new keyword be necessary?
C++ made enums stricter by "enum class".
On Tuesday, 29 September 2020 at 16:03:39 UTC, IGotD- wrote:
That little simple example shows that you don't necessarily
need to know things in advance in order to have static
lifetimes. However, there are examples where there is no
possibility for the compiler to infer when the object goes out
On Thursday, 1 October 2020 at 00:13:41 UTC, IGotD- wrote:
For example completely lockless algorithms can often be a
combination of atomic operations and also non-atomic operations
on data members.
Also, atomic operations on members do not ensure the integrity of
the struct. For that you need
On Sunday, 11 October 2020 at 11:56:29 UTC, Robert M. Münch wrote:
environment... I don't know about any other language which puts
all these non-technical aspects on the top of the agenda.
Ada, Java, Eiffel are supposed to.
I'm not sure if Go is a success in that department either. I
suspect
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:
Go seems to be kept as simple as possible, even if you have to
write more code. Which is, in the long run, the cheaper and
smaller burden. No tricks, no surprises... that has a lot of
merits.
Yes, it is a good fit for web serv
On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote:
Even most people seem to use Go for the web services stuff, I
think it might be underrate for desktop apps.
Go is good at what it has Go libraries for, and I believe it has
gotten quite a few over the past years, some that has
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote:
Go seems to be kept as simple as possible, even if you have to
write more code. Which is, in the long run, the cheaper and
smaller burden. No tricks, no surprises... that has a lot of
merits.
Btw, Go has some major weaknesses
On Thursday, 22 October 2020 at 17:25:44 UTC, Bruce Carneal wrote:
Is type checking in D undecidable? Per the wiki on dependent
types it sure looks like it is.
Even if it is, you can still write something that is decidable in
D, but impractical in terms of compile time.
You probably mean mo
On Thursday, 22 October 2020 at 18:24:47 UTC, Bruce Carneal wrote:
Per the wiki on termination analysis some languages with
dependent types (Agda, Coq) have built-in termination checkers.
I assume that DMD employs something short of such a checker,
some combination of cycle detection backed up
On Thursday, 22 October 2020 at 18:38:12 UTC, Stefan Koch wrote:
On Thursday, 22 October 2020 at 18:33:52 UTC, Ola Fosheim
Grøstad wrote:
In general, it is hard to tell if a computation is
long-running or unsolvable.
You could even say ... it's undecidable :)
:-) Yes, although you can impo
On Thursday, 22 October 2020 at 19:24:53 UTC, Bruce Carneal wrote:
I dont think it is any easier to prove the "will increase
faster" proposition than it is to prove the whole thing.
They probably just impose restrictions so that they prove that
there is reduction and progress over time. One co
On Thursday, 29 October 2020 at 08:13:42 UTC, Jan Hönig wrote:
Regarding the shared keyword, I am not sure if immutables are
shared per default. I thought they are not.
You can test this with is(TYPE1==TYPE2)
is(shared(immutable(int))==immutable(int))
The class definition for Object in the runtime object.d is
"empty". Where can I find a description of the structure and
fields of "class Object"?
On Thursday, 29 October 2020 at 14:06:08 UTC, Adam D. Ruppe wrote:
On Thursday, 29 October 2020 at 14:03:46 UTC, Ola Fosheim
Grøstad wrote:
The class definition for Object in the runtime object.d is
"empty". Where can I find a description of the structure and
fields of "class Object"?
http://
On Thursday, 29 October 2020 at 16:09:00 UTC, Adam D. Ruppe wrote:
The internal rt namespace is also on my website:
http://dpldocs.info/experimental-docs/rt.html
but of course that's private so you can't import it from user
code.
Thanks, that might be useful later :-).
On Thursday, 29 October 2020 at 16:09:10 UTC, kinke wrote:
On Thursday, 29 October 2020 at 16:02:34 UTC, Ola Fosheim
Grøstad wrote:
I meant the internals like vtable/typeinfo.
https://dlang.org/spec/abi.html#classes
Thanks!
On Thursday, 29 October 2020 at 14:39:31 UTC, H. S. Teoh wrote:
On Thu, Oct 29, 2020 at 09:50:28AM -0400, Steven Schveighoffer
via Digitalmars-d-learn wrote: [...]
D frequently allows no-op attributes.
[...]
I find that to be a bad smell in terms of language design,
actually. Either something
I want to implement a generic function for "a < f(x) < b" that
will give the same result as "(a < f(x)) && (f(x) < b)" for any
conceivable mix of types. Except if that "f(x)" should only be
evaluated once.
Is it sufficient to use "scope ref" in parameters?
I don't want to assume _anything_ ab
On Tuesday, 10 November 2020 at 17:09:00 UTC, Paul Backus wrote:
bool between(Value, Bound)(auto ref Value value, auto ref Bound
low, auto ref Bound high)
{
return (low < value) && (value < high);
}
You need `auto ref` because either Bound or Value may have
copying disabled. Because the fu
On Tuesday, 10 November 2020 at 20:32:40 UTC, Paul Backus wrote:
The compiler infers pure, @nogc, nothrow etc. for template
functions automatically. It's actually better if you don't add
them by hand.
Ok, thanks :-).
On Tuesday, 10 November 2020 at 01:00:50 UTC, Mark wrote:
I haven't looked into the newest C++. In theory, they might
have added something helpful in the past years.
I guess you could say that the latest version of C++ allows you
to write code that is a little bit less verbose than before. C++
On Wednesday, 11 November 2020 at 13:30:16 UTC, Simen Kjærås
wrote:
The short answer is 'because that's how we've chosen to define
it'. A more involved answer is that changing every reference is
prohibitively expensive - it would require the equivalent of a
GC collection on every reallocation,
On Tuesday, 17 November 2020 at 13:24:03 UTC, Kagamin wrote:
On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe
wrote:
On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:
Is this intentional?
In the current language design, yes.
It's a bug, it breaks data sharing guarante
1 - 100 of 387 matches
Mail list logo
