On Sunday, 18 June 2017 at 14:16:03 UTC, Basile B. wrote:
On Sunday, 18 June 2017 at 09:41:01 UTC, Johannes Loher wrote:
Hey, I'm trying to work on
https://issues.dlang.org/show_bug.cgi?id=15708 so I decided it
might be interesting to find a way to (recursively) call all
postblits that belong
On Wed, 2017-06-21 at 10:23 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> […]
>
> The reason the GC must be conservative is because (1) D is a systems
> programming language, and also because (2) D interfaces directly with
> C.
I think the term "systems programming language" contains no actu
Hi,
I created a custom type which enables me to have enums which have
in their initial state, the init value of their base type.
Something similiar to Nullable...
enum Reason : string {CO = "Co", FU = "Fu", CA = "Ca"}
struct TestStruct {InitialEnum!Reason reason;}
This line raises the error:
On Thursday, 22 June 2017 at 09:45:09 UTC, Russel Winder wrote:
I think the term "systems programming language" contains no
actual data, so needs to be retired. In this situation it
provides no reason for conservative garbage collection.
It means the intent of language designer to let you writ
On 06/22/2017 12:34 PM, Boris-Barboris wrote:
Everything the language allows to compile is allowed by it's type
system, or is a bug in the compiler.
No. D is not supposed to be completely verifiable by the compiler.
For example, the type system guarantees that immutable data never
changes. Bu
I should preface this by saying I don't really have a good sense
of how either BetterC or the D runtime work.
The recent BetterC thread made me wonder about TypeInfo in the D
runtime. My (surface level) understanding is that this is what
makes typeid work at run time.
I was looking through t
On Thursday, 22 June 2017 at 14:30:31 UTC, jmh530 wrote:
I was looking through the C++ standard library headers and
noticed that has a typeid also. One difference with
D is that it is opt-in as there is some cost using it.
C++ also leaves most the properties for typeinfo to be
implementation
On Thursday, 22 June 2017 at 14:50:45 UTC, Adam D. Ruppe wrote:
[snip]
I appreciate the reply.
On 6/21/17 1:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn
wrote:
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it sees
something that *mig
On Thursday, 22 June 2017 at 05:57:59 UTC, bauss wrote:
On Wednesday, 21 June 2017 at 15:55:27 UTC, David Nadlinger
wrote:
On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer
wrote:
Fresh install of GDC. (tried with 32x ad 32_64x)
Where did you get the GDC executable from? The GDC proje
Hi,
i often need to check whether an array(string) ends with a
specific text and if not I need to add this text.
For example I have a variable url and / has to be added to the
end in case it is missing.
I want to write:
...new RegistryPackageSupplier(URL(url.enforceSuffix("/"))...
Of cours
On Thu, Jun 22, 2017 at 06:18:22PM +, Andre Pany via Digitalmars-d-learn
wrote:
> Hi,
>
> i often need to check whether an array(string) ends with a specific
> text and if not I need to add this text.
>
> For example I have a variable url and / has to be added to the end in
> case it is miss
On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote:
For example, the type system guarantees that immutable data
never changes. But the compiler allows you to cast from
immutable to mutable and change the data. It's an invalid
operation, but the compiler is not expected to catch that for
Hi
https://dpaste.dzfl.pl/0def4e286564
Is there a cleaner way to go than the one on the line 26? And why
is the constructor
/d475/f781.d(37): f781.UniquePtr!(A).UniquePtr.__ctor(DT)(ref
scope UniquePtr!DT rhs)
unfit for line 51?
Is it because the expression " = UniquePtr!B.make()" cannot b
On Thursday, 22 June 2017 at 18:38:59 UTC, Boris-Barboris wrote:
On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote:
For example, the type system guarantees that immutable data
never changes. But the compiler allows you to cast from
immutable to mutable and change the data. It's an inval
On 06/22/2017 12:06 PM, Boris-Barboris wrote:
> Hi
>
> https://dpaste.dzfl.pl/0def4e286564
>
> Is there a cleaner way to go than the one on the line 26? And why is the
> constructor
>
> /d475/f781.d(37): f781.UniquePtr!(A).UniquePtr.__ctor(DT)(ref scope
> UniquePtr!DT rhs)
>
> unfit for line 51?
>
On Thursday, 22 June 2017 at 19:11:19 UTC, Cym13 wrote:
Here it's the programmer's fault really. You should never use
casts in normal code, cast is the ultimate switch to say "Look,
I know what I'm doing, so disable all safety, don't try to make
sense of it, and let me do my thing. If I'm telli
On Thursday, 22 June 2017 at 19:17:13 UTC, Ali Çehreli wrote:
No time to think about the rest of the design but just to get
the code compiled, replace 'ref' with 'auto ref' like so:
this(DT)(scope auto ref UniquePtr!DT rhs)
{
// ...
}
Ali
i added this static variable:
st
On 06/22/2017 08:38 PM, Boris-Barboris wrote:
Casts are part of the type system. Yes, D type system allows invalid
operations. It's not the compiler's fault, it's type system's fault.
unittest
{
immutable int a = 4;
int* b = cast(int*) &a;
*b = 5;
assert(*(&a) == 5);
as
On Thursday, 22 June 2017 at 19:17:13 UTC, Ali Çehreli wrote:
No time to think about the rest of the design but just to get
the code compiled, replace 'ref' with 'auto ref' like so:
Ok, looks like this indeed passes rhs by reference, thank you.
destcalls - number of times UniquePtr destructor
On 06/22/2017 12:57 PM, Boris-Barboris wrote:
> On Thursday, 22 June 2017 at 19:17:13 UTC, Ali Çehreli wrote:
>> No time to think about the rest of the design but just to get the code
>> compiled, replace 'ref' with 'auto ref' like so:
>
> Ok, looks like this indeed passes rhs by reference, thank
On Thursday, 22 June 2017 at 20:05:46 UTC, Ali Çehreli wrote:
To be complete, 'auto ref' passes lvalues by reference and
rvalues by value, which you can detect with __traits(isRef):
struct S{
}
void foo()(auto ref S s) {
static if (__traits(isRef, s)) {
pragma(msg, "lvalue");
}
On 06/22/2017 02:08 PM, Boris-Barboris wrote:
On Thursday, 22 June 2017 at 20:05:46 UTC, Ali Çehreli wrote:
To be complete, 'auto ref' passes lvalues by reference and rvalues by
value, which you can detect with __traits(isRef):
struct S{
}
void foo()(auto ref S s) {
static if (__traits(isR
On Thursday, 22 June 2017 at 21:16:40 UTC, Ali Çehreli wrote:
And yes, there should be one destructor, which may be a no-op
if you grab its resource and set it to null.
On all compilers...
That's a relief, thank you for your help.
Currently a lot of language features generate dependencies on
TypeInfo, arguably more than needed, but this is changing. Some
examples are in this DConf 2017 talk:
https://www.youtube.com/watch?v=endKC3fDxqs
Also, the way the language is designed right now, all modules are
responsible for co
On Thursday, 22 June 2017 at 21:19:43 UTC, Boris-Barboris wrote:
On Thursday, 22 June 2017 at 21:16:40 UTC, Ali Çehreli wrote:
And yes, there should be one destructor, which may be a no-op
if you grab its resource and set it to null.
On all compilers...
That's a relief, thank you for your he
On Friday, 23 June 2017 at 00:54:36 UTC, Petar Kirov [ZombineDev]
wrote:
On Thursday, 22 June 2017 at 21:19:43 UTC, Boris-Barboris wrote:
On Thursday, 22 June 2017 at 21:16:40 UTC, Ali Çehreli wrote:
And yes, there should be one destructor, which may be a no-op
if you grab its resource and set
On Friday, 23 June 2017 at 00:41:11 UTC, sarn wrote:
Does it matter? C++ programmers already accept that RTTI is
needed for certain dynamic features.
Yes, it is necessary, but how much? Can we do it with implicitly
generated library code?
I'm pretty sure the answer is "not much" and "yes",
On Friday, 23 June 2017 at 02:14:08 UTC, Adam D. Ruppe wrote:
Yes, it is necessary, but how much? Can we do it with
implicitly generated library code?
I'm pretty sure the answer is "not much" and "yes", but I still
need to ponder the details. I think the typeinfo for a class
good enough for
On Friday, 23 June 2017 at 02:49:27 UTC, Mike wrote:
I'm not sure what you have in mind, but TypeInfo in itself is
not bad and has some very useful features even for resource
constrained devices and other niche domains.
Yeah, I agree with you.
My approaches are right now for -betterC to be a
auto foo(Args...)(ref Args args)
{
with (Module!"std.conv")
with (Module!"std.stdio") {
return () => {
string[] s;
foreach (i, arg; args) {
static if (is(Args[i] == string)) {
s ~= arg;
} else {
Andrew Edwards wrote:
I desire to call foo() at compile... As implemented it does not happen,
but it's not immediately clear what I am missing. Or is this simply not
possible as yet? What is the proper way to redesign this template so that
it will execute at compile time?
there are two cave
On Friday, 23 June 2017 at 04:58:07 UTC, ketmar wrote:
Andrew Edwards wrote:
so no, even if you'll remove `ref`, it will not work. sorry.
Okay, got it. Much appreciated.
33 matches
Mail list logo
