On Tuesday, 26 June 2018 at 00:56:13 UTC, Jonathan M Davis wrote:
On Monday, June 25, 2018 23:13:12 Seb via Digitalmars-d wrote:
- Jonathan M Davis
I've tried to fix this issue. If briefly there is one collision:
Final alias this should be r-value:
static struct S
{
int i;
}
void test(re
On Wednesday, 20 January 2016 at 00:45:34 UTC, Walter Bright
wrote:
On 1/19/2016 1:59 PM, Daniel Murphy wrote:
On 19/01/2016 8:04 PM, Walter Bright wrote:
On 1/19/2016 12:34 AM, Daniel Murphy wrote:
Yeah, it never has. No attempt has ever been made to make
it work.
Actually, as I recall it
On Thursday, 18 June 2015 at 02:54:00 UTC, Morbid.Obesity wrote:
On Wednesday, 17 June 2015 at 16:16:09 UTC, berlin wrote:
well, read something to your world situation. take it from an
old kufr that dos not want to live under islamic law:
http://www.jihadwatch.org/
http://www.thereligionofpeac
On Thursday, 18 June 2015 at 02:22:13 UTC, Vladimir Panteleev
wrote:
On Wednesday, 17 June 2015 at 18:35:48 UTC, Andrei Alexandrescu
wrote:
With this we revoke Martin's role as release czar. His github
access will remain the same for the time being.
I think that was unnecessarily harsh and uni
On Wednesday, 17 June 2015 at 02:16:37 UTC, Andrei Alexandrescu
wrote:
Hello,
Martin has not replied to any communication for more than two
weeks now, and I'm starting to fear something might have
happened to him. If anyone in Berlin could get in touch with
him and let me/us know he's alrigh
Hello, comrades. Lets put into the schedule reviewing of this PR
(https://github.com/D-Programming-Language/dmd/pull/3998).
It contains a very much changes and it is hard to maintain its
performance: each foreign PR may break it.
On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu wrote:
FYI I just created
https://issues.dlang.org/show_bug.cgi?id=14638 as one of
possibly several language enhancements to improve usability of
noncopyable types (most allocators are not copyable) and to
enhance performance of objec
On Saturday, 30 May 2015 at 15:24:49 UTC, Adam D. Ruppe wrote:
On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote:
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
I briefly mentioned this at the dconf and thinking about it a
bit more, I think there's only two cases w
struct Foo
{
int a;
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
{
return Foo(val);
}
}
void test(Foo foo, int i)
{
assert(foo.a == i);
}
test(42, 42); ->
test(Foo.opImplicitConstructFrom(42), 42);
On Saturday, 30 May 2015 at 08:51:31 UTC, Vladimir Panteleev
wrote:
On Saturday, 30 May 2015 at 08:50:21 UTC, Vladimir Panteleev
wrote:
http://localhost/post/asvcbsvfcxznwypttojk@192.168.0.1
Sorry, working link:
http://forum.dlang.org/post/asvcbsvfcxznwypttojk@192.168.0.1
We may say that AA
On Friday, 29 May 2015 at 22:41:13 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
One that doesn't break any code, carefully deprecates necessa
On Friday, 29 May 2015 at 21:41:12 UTC, Andrei Alexandrescu wrote:
On 5/29/15 3:37 PM, IgorStepanov wrote:
On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu
wrote:
On 5/25/15 3:01 PM, IgorStepanov wrote:
Ok, I've applied your changes to the DIP page, and I'm
starting to
rework my gi
On Friday, 29 May 2015 at 17:52:58 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
What do you want about this syntax? Maybe you may suggest a
better solution?
The discussion drifts a little OT, if we have opIndexCreate,
then the library AA can be more com
On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu
wrote:
On 5/25/15 3:01 PM, IgorStepanov wrote:
Ok, I've applied your changes to the DIP page, and I'm
starting to
rework my github PR. Sorry for the slow work (I'm very busy
last time).
However I still working. Stay on line=)
Thank
On Friday, 29 May 2015 at 12:52:29 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 11:22:53 UTC, IgorStepanov wrote:
Sorry, I meant
f.opIndex!(true)(5).opIndexAssign(Foo(42), 3);
Added to the ER.
https://issues.dlang.org/show_bug.cgi?id=7753#c6
Thanks, but unfortunately, writing enhacemen
On Friday, 29 May 2015 at 11:17:00 UTC, Martin Nowak wrote:
On Wednesday, 27 May 2015 at 17:16:53 UTC, IgorStepanov wrote:
Foo f;
f[5][3] = Foo(42); translates to
f.opIndex!(true)(5).opIndex!(true)(3) = Foo(42);
auto x = f[5][4]; translates to
auto x = f.opIndex!(false)(5).opIndex!(false)
On Wednesday, 27 May 2015 at 14:12:02 UTC, Martin Nowak wrote:
On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev
wrote:
Could you elaborate on what these magic semantics are?
and no easy solution exists for the ++aa[key1][key2] case.
Is this specific to the pre-increment? aa[key1][k
On Monday, 25 May 2015 at 23:36:00 UTC, Timon Gehr wrote:
On 05/26/2015 01:17 AM, IgorStepanov wrote:
My example:
auto foo(T)(){ return 1; }
auto foo(T)()if(is(T: int)){ return 2; }
struct Foo
{
//...
}
struct Bar
{
Foo f;
int i;
alias i this;
}
auto ret = foo!Bar;
assert(
On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Looks like a good step in the right direction.
Some qu
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
BTW, I have one idea. We may declare the AA ABI:
AA is a pointer to the next layout:
__vtbl
N bytes of data
and __vtbl i
On Monday, 25 May 2015 at 22:32:55 UTC, Timon Gehr wrote:
On 03/29/2015 07:34 PM, IgorStepanov wrote:
3. is(T: B) should raise an error if there are many ways to
convert T to B.
This is inconsistent with how 'is' works otherwise, and it
breaks template constraints in annoying ways. (There i
On Tuesday, 31 March 2015 at 20:01:14 UTC, Andrei Alexandrescu
wrote:
On 3/31/15 7:28 AM, IgorStepanov wrote:
On Monday, 30 March 2015 at 18:33:17 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 8:04 AM, Steven Schveighoffer wrote:
On 3/29/15 1:34 PM, IgorStepanov wrote:
1. We should reject types
On Monday, 30 March 2015 at 18:33:17 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 8:04 AM, Steven Schveighoffer wrote:
On 3/29/15 1:34 PM, IgorStepanov wrote:
1. We should reject types which use opDispatch and alias this
at the
same time.
Why? Alias this has no filter. opDispatch can use temp
On Monday, 30 March 2015 at 15:04:20 UTC, Steven Schveighoffer
wrote:
On 3/29/15 1:34 PM, IgorStepanov wrote:
1. We should reject types which use opDispatch and alias this
at the
same time.
Why? Alias this has no filter. opDispatch can use template
constraints. It makes perfect sense to pre
On Sunday, 29 March 2015 at 08:03:37 UTC, deadalnix wrote:
On Saturday, 28 March 2015 at 19:52:15 UTC, IgorStepanov wrote:
http://wiki.dlang.org/DIP66
First I want to apologize for the long absence.
I was very busy for those months and now I ready to continue
the work.
This DIP has been appr
http://wiki.dlang.org/DIP66
First I want to apologize for the long absence.
I was very busy for those months and now I ready to continue the
work.
This DIP has been approved with three clarifications:
about is-expression, about opDispatch and about "common"
inheritance.
I've reflected those c
On Saturday, 20 December 2014 at 21:25:28 UTC, Andrei
Alexandrescu wrote:
On 11/2/14 6:57 AM, IgorStepanov wrote:
And there is dispute about is expression: see
http://forum.dlang.org/thread/ubafmwvxwtolhmnxb...@forum.dlang.org?page=5
OK, time to get this approved.
First, the current DIP doesn
Bump
On Sunday, 16 November 2014 at 09:28:25 UTC, Rainer Schuetze
wrote:
On 15.11.2014 23:40, IgorStepanov wrote:
Do I any fundamental error in this code?
May be Bucket[] ret = new Bucket[len]; ret.ptr is not base
pointer?
Yes, for arrays larger than 2kB, the allocation length
information is pl
On Saturday, 15 November 2014 at 03:41:56 UTC, Steven
Schveighoffer wrote:
On 11/14/14 8:56 PM, IgorStepanov wrote:
On Friday, 14 November 2014 at 23:49:00 UTC, ketmar via
Digitalmars-d
wrote:
On Fri, 14 Nov 2014 23:23:17 +
IgorStepanov via Digitalmars-d
wrote:
What does the
On Friday, 14 November 2014 at 23:49:00 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 14 Nov 2014 23:23:17 +
IgorStepanov via Digitalmars-d
wrote:
What does the NO_INTERIOR flag?
it stops GC to acknowledge pointers inside allocated area as
anchors.
i.e. if there is no pointer to the
On Friday, 14 November 2014 at 23:12:05 UTC, IgorStepanov wrote:
On Friday, 14 November 2014 at 22:38:53 UTC, Steven
Schveighoffer wrote:
On 11/14/14 5:25 PM, Dmitry Olshansky wrote:
15-Nov-2014 01:16, IgorStepanov пишет:
Recently I encountered the following problem.
I need a simple stack of u
On Friday, 14 November 2014 at 22:38:53 UTC, Steven Schveighoffer
wrote:
On 11/14/14 5:25 PM, Dmitry Olshansky wrote:
15-Nov-2014 01:16, IgorStepanov пишет:
Recently I encountered the following problem.
I need a simple stack of uint.
I want to push uints back and pop it. I don't want to copy
t
On Friday, 14 November 2014 at 22:25:20 UTC, Dmitry Olshansky
wrote:
15-Nov-2014 01:16, IgorStepanov пишет:
Recently I encountered the following problem.
I need a simple stack of uint.
I want to push uints back and pop it. I don't want to copy
this stack
and I want it to work fast.
In a first
Recently I encountered the following problem.
I need a simple stack of uint.
I want to push uints back and pop it. I don't want to copy this
stack and I want it to work fast.
In a first approximation, the problem seems easy.
uint[] my_stack;
my_stack.reserve(256);
my_stack ~= 1; //push
uint h
On Thursday, 13 November 2014 at 09:57:04 UTC, Marc Schütz wrote:
On Wednesday, 12 November 2014 at 21:17:42 UTC, IgorStepanov
wrote:
On Wednesday, 12 November 2014 at 20:49:42 UTC, Marc Schütz
wrote:
On Wednesday, 12 November 2014 at 19:32:32 UTC, IgorStepanov
wrote:
On Wednesday, 12 November
On Wednesday, 12 November 2014 at 20:49:42 UTC, Marc Schütz wrote:
On Wednesday, 12 November 2014 at 19:32:32 UTC, IgorStepanov
wrote:
On Wednesday, 12 November 2014 at 14:41:17 UTC, Marc Schütz
wrote:
On Wednesday, 12 November 2014 at 11:43:36 UTC, IgorStepanov
wrote:
C++ and D provides differ
On Wednesday, 12 November 2014 at 14:41:17 UTC, Marc Schütz wrote:
On Wednesday, 12 November 2014 at 11:43:36 UTC, IgorStepanov
wrote:
C++ and D provides different behaviour for operator
overloading.
D has a opIndex + opIndexAssign overloads, and if we want to
map opIndex to operator[], we must
On Wednesday, 12 November 2014 at 02:37:52 UTC, deadalnix wrote:
On Tuesday, 11 November 2014 at 22:26:48 UTC, IgorStepanov
wrote:
Now D provides very powerfull means to link C++ code with D.
However D doesn't allow to call C++ overloaded operators.
It's very annoying, because C++ code may don't
Now D provides very powerfull means to link C++ code with D.
However D doesn't allow to call C++ overloaded operators.
It's very annoying, because C++ code may don't provide
non-operator analogues.
What we know about C++ overloadable operators? Overloaded
operator in C++ is a trivial function/me
On Wednesday, 5 November 2014 at 20:33:40 UTC, Adam D. Ruppe
wrote:
On Wednesday, 5 November 2014 at 20:19:03 UTC, IgorStepanov
wrote:
data[i].__postblit(); //error: S hasn't __postblit member, but
it need the postblit call for Sx
Hmm, we could perhaps do a recursive call with
__traits(allMem
FYI:
My second try:
void emplace(V1)(ref V1 dst, ref V1 src) @trusted if (is(V1 ==
struct))
{
static if (new_obj)
{
V1 tmp = cast(V1)src; //create copy and call postblit
static V1 init = V1.init;
//bitwise copy of object, which already postblitted
(cast(v
On Wednesday, 5 November 2014 at 20:01:59 UTC, Adam D. Ruppe
wrote:
If you're willing to make it @system or @trusted, you can just
copy the data and call postblit manually:
extern(C) @safe int printf(in char*);
struct S {
~this() { printf("dtor\n"); }
this(this) { printf("postb
Please try to solve this task:
We have a struct S.
S has a some kind of postblit (user-defined or inherited frome
field) and destructor. S has a @disabled opAssign.
We have an unitialized allocated memory block whick mapped to a S
array.
struct S
{
//postblit and dtor here
}
S[] data; // con
On Monday, 3 November 2014 at 20:06:27 UTC, Marc Schütz wrote:
On Monday, 3 November 2014 at 15:39:42 UTC, IgorStepanov wrote:
I meant that when you say that X is a subtype of T and X is a
subtype of V where you don't know what T and V are, it means
you don't really know what you're doing. And
* "At the AliasThis declaration semantic stage, the compiler
can
perform the initial checks and reject the obviously incorrect
AliasThis declarations." -> it might be simpler (for the sake
of
simplifying generic code) to just delay all error checking to
the
first use.
I disagree with that. C
And there is dispute about is expression: see
http://forum.dlang.org/thread/ubafmwvxwtolhmnxb...@forum.dlang.org?page=5
http://wiki.dlang.org/DIP66
I've applied some changes to it, however there are still some
unresolved questions.
Here's my destruction:
* "symbol can be a field or a get-property (method annotated
with @property and taking zero parameters)." -> actually:
(a) the @property annotation is not
On Tuesday, 28 October 2014 at 23:12:21 UTC, Meta wrote:
On Tuesday, 28 October 2014 at 22:55:24 UTC, IgorStepanov wrote:
You may see isFloatingPoint declaration in traits.d:
enum bool isFloatingPoint(T) = is(FloatingPointTypeOf!T) &&
!isAggregateType!T;
This template explicitly says that T s
On Tuesday, 28 October 2014 at 21:55:35 UTC, Meta wrote:
On Tuesday, 28 October 2014 at 20:09:07 UTC, IgorStepanov wrote:
And please comment my way to resolving "is" expression via
alias-this:
http://forum.dlang.org/thread/ubafmwvxwtolhmnxb...@forum.dlang.org?page=5
Something else related to
On Tuesday, 28 October 2014 at 19:45:09 UTC, Andrei Alexandrescu
wrote:
On 10/10/14 10:09 AM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
Here's my destruction:
* "s
On Tuesday, 28 October 2014 at 02:07:23 UTC, Andrei Alexandrescu
wrote:
On 10/24/14 6:05 AM, IgorStepanov wrote:
On Friday, 24 October 2014 at 06:04:24 UTC, Andrei
Alexandrescu wrote:
On 10/19/14 2:00 PM, IgorStepanov wrote:
Bump.
I've made a few grammar and fluency edits to the DIP, and
co
On Friday, 24 October 2014 at 13:17:28 UTC, Meta wrote:
On Friday, 24 October 2014 at 13:05:54 UTC, IgorStepanov wrote:
On Friday, 24 October 2014 at 06:04:24 UTC, Andrei
Alexandrescu wrote:
On 10/19/14 2:00 PM, IgorStepanov wrote:
Bump.
I've made a few grammar and fluency edits to the DIP,
On Friday, 24 October 2014 at 06:04:24 UTC, Andrei Alexandrescu
wrote:
On 10/19/14 2:00 PM, IgorStepanov wrote:
Bump.
I've made a few grammar and fluency edits to the DIP, and
collected a few thoughts while doing that. Will get back on
this before too long. -- Andrei
I've seen it. Thanks!
On Tuesday, 21 October 2014 at 08:17:19 UTC, Dicebot wrote:
On Sunday, 19 October 2014 at 21:00:29 UTC, IgorStepanov wrote:
Bump.
For me current description and PR look solid and safe enough to
try.
We are waiting for an Andrey's Word. Walter, as I understand
haven't unresolved objections.
On Monday, 20 October 2014 at 00:23:46 UTC, Daniel N wrote:
On Wednesday, 15 October 2014 at 09:50:17 UTC, IgorStepanov
wrote:
In first edition I've implemented rule, when if type defines
alias this directly, this alias hides all indirect aliases
with the same type. However Andrey said that we
Bump.
On Friday, 17 October 2014 at 19:45:43 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 19:39:39 +
IgorStepanov via Digitalmars-d
wrote:
Thus I suggest another solution:
Do not generate helper functions like __fieldPostBlit, if
struct has a @disabled this(this);
Destroy it
On Friday, 17 October 2014 at 17:25:47 UTC, monarch_dodra wrote:
On Friday, 17 October 2014 at 16:19:47 UTC, IgorStepanov wrote:
It's just common words=)
I meant that when postblit is called when new object is being
creating and doesn't exists for user code.
E.g.
const S v1 = v2;
Ok, v1 _will_
On Friday, 17 October 2014 at 15:20:50 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 14:41:36 +
IgorStepanov via Digitalmars-d
wrote:
What happends if we will ignore const/immutable modifier for
postblits? Is it create any holes?
it will break "const promise". i
On Friday, 17 October 2014 at 14:18:31 UTC, monarch_dodra wrote:
On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 00:42:24 +
IgorStepanov via Digitalmars-d
wrote:
Can someone comment this code? Should I think that it's a bug.
it'
On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 00:42:24 +
IgorStepanov via Digitalmars-d
wrote:
Can someone comment this code? Should I think that it's a bug.
it's just an anomaly. const postblit can do alot of things
besides
I've found a strange postblit bug (or not a bug?):
struct A
{
this(this)
{
}
}
struct B
{
A a;
}
struct C
{
const B b;
}
void main()
{
C c;
}
When I try to compile it, compiler raises the erro
On Wednesday, 15 October 2014 at 03:49:41 UTC, Daniel N wrote:
On Wednesday, 15 October 2014 at 02:46:05 UTC, Dicebot wrote:
On Tuesday, 14 October 2014 at 12:33:50 UTC, IgorStepanov
wrote:
This code tell that C is subtype of A and C is subtype of B.
User can use this fact in his code:
void foo
On Monday, 13 October 2014 at 15:21:32 UTC, Daniel N wrote:
On 10/11/2014 7:23 AM, IgorStepanov wrote:
class A
{
int i;
alias i this;
}
class B
{
int i;
alias i this;
}
class C
{
A a;
B b;
alias a this;
alias b this;
}
My preferred solution would be to reject the 2nd alias
declaration outri
On Monday, 13 October 2014 at 00:54:13 UTC, Steven Schveighoffer
wrote:
On 10/12/14 7:16 PM, IgorStepanov wrote:
On Sunday, 12 October 2014 at 23:02:13 UTC, Steven
Schveighoffer wrote:
On 10/10/14 6:10 PM, IgorStepanov wrote:
You can write foo(c.shadow); This isn't hard.
Ok, I understood you
Advantage of ky way is a more strictness then your way: if
function with if(is(T: S)) will be called, error will be raised
at the first trying of convert T to S. And we don't give the
opportunity of possible error to spread away from the place of
origin.
On Sunday, 12 October 2014 at 23:02:13 UTC, Steven Schveighoffer
wrote:
On 10/10/14 6:10 PM, IgorStepanov wrote:
On Friday, 10 October 2014 at 21:26:49 UTC, Steven
Schveighoffer wrote:
An example:
foo(T)(T t) if(is(T : int))
{
someFuncThatTakesInt(t);
}
foo(T)(T t) if(!is(T : int) && is(T
On Sunday, 12 October 2014 at 08:36:05 UTC, Marc Schütz wrote:
On Sunday, 12 October 2014 at 04:31:22 UTC, Walter Bright wrote:
On 10/11/2014 7:23 AM, IgorStepanov wrote:
class A
{
int i;
alias i this;
}
class B
{
int i;
alias i this;
}
class C
{
A a;
B b;
alias a this;
alias
On Saturday, 11 October 2014 at 00:00:48 UTC, Walter Bright wrote:
On 10/10/2014 4:23 PM, IgorStepanov wrote:
On Friday, 10 October 2014 at 22:50:25 UTC, Walter Bright
wrote:
must be an error, even if one of C.a() or C.b() might be a
"better" match.
This is how things work for template mixins
On Friday, 10 October 2014 at 22:51:34 UTC, Walter Bright wrote:
On 10/10/2014 3:46 PM, Timon Gehr wrote:
On 10/11/2014 12:29 AM, Walter Bright wrote:
On 10/10/2014 3:06 PM, Timon Gehr wrote:
On 10/10/2014 11:25 PM, Walter Bright wrote:
Essentially, the rules for multiple alias this should b
BTW.
Overloaded functions in PR resolves un-properly (raises error
even if can be resolved correct function)
However it's easy to fix and I'll do it tomorrow.
On Friday, 10 October 2014 at 22:50:25 UTC, Walter Bright wrote:
On 10/10/2014 3:20 PM, IgorStepanov wrote:
The same issue also needs to be considered if A and B are
structs instead and
B has an additional alias this to an A (the solution might
also be part of a
fix for the cycle issue).
- "I
On Friday, 10 October 2014 at 22:18:36 UTC, Timon Gehr wrote:
On 10/11/2014 12:07 AM, IgorStepanov wrote:
On Friday, 10 October 2014 at 21:25:17 UTC, Walter Bright
wrote:
If 'a' and 'b' both contain overloads for function foo, then
it should
behave like imports do (which is a bit complex).
On Friday, 10 October 2014 at 22:05:18 UTC, Timon Gehr wrote:
On 10/10/2014 07:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
- "C c;
int i = c; //Error: c.a.i vs
On Friday, 10 October 2014 at 21:26:49 UTC, Steven Schveighoffer
wrote:
On 10/10/14 5:15 PM, IgorStepanov wrote:
On Friday, 10 October 2014 at 20:47:45 UTC, Steven
Schveighoffer wrote:
On 10/10/14 1:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP
On Friday, 10 October 2014 at 21:25:17 UTC, Walter Bright wrote:
On 10/10/2014 10:09 AM, IgorStepanov wrote:
Please, comment it.
> static assert(is(C : int)); //Ok, because C is subtype of int
anyway.
Comment should say that C is implicitly convertible to int
Not really.
int i = C(); //conf
On Friday, 10 October 2014 at 20:44:11 UTC, Marc Schütz wrote:
On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
I understand th
On Friday, 10 October 2014 at 20:47:45 UTC, Steven Schveighoffer
wrote:
On 10/10/14 1:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
This part:
void test()
{
Which will now create an error in the wrong place. IMO, the
'is' test should also fail.
-Steve
In this case, you will see the real error and will able to fix
if. For example call foo(c.a); Otherwice, you possible error will
be fixed without taking into account your opinions.
On Friday, 10 October 2014 at 20:29:43 UTC, Brian Schott wrote:
On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
There is an er
On Friday, 10 October 2014 at 17:31:23 UTC, Steven Schveighoffer
wrote:
On 10/10/14 1:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
Hm... not sure you need a DIP.
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
On Saturday, 27 September 2014 at 23:31:17 UTC, Andrei
Alexandrescu wrote:
On 9/27/14, 1:31 PM, IgorStepanov wrote:
No, that for throwing from C++ into D: for catch an exception,
we should
pass type_info object to special C++ runtime function. C++
runtime
determines, can throwed object type can
On Saturday, 27 September 2014 at 20:11:34 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 27 September 2014 10:53, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-09-23 19:37, Andrei Alexandrescu wrote:
We need a libunwind expert to figure out a good approach for
handling
exceptions thrown by
On Saturday, 27 September 2014 at 20:18:42 UTC, Andrei
Alexandrescu wrote:
On 9/27/14, 12:53 PM, IgorStepanov wrote:
On Saturday, 27 September 2014 at 18:33:24 UTC, Jacob Carlborg
wrote:
On Saturday, 27 September 2014 at 11:34:32 UTC, IgorStepanov
wrote:
C++ exception mechanism uses C++ type_
On Saturday, 27 September 2014 at 19:16:24 UTC, Andrei
Alexandrescu wrote:
On 9/27/14, 2:53 AM, Jacob Carlborg wrote:
On 2014-09-23 19:37, Andrei Alexandrescu wrote:
We need a libunwind expert to figure out a good approach for
handling
exceptions thrown by C++ code into D.
BTW, are you only
On Saturday, 27 September 2014 at 18:33:24 UTC, Jacob Carlborg
wrote:
On Saturday, 27 September 2014 at 11:34:32 UTC, IgorStepanov
wrote:
C++ exception mechanism uses C++ type_info objects. We can
inherit object.Throwable from std::exception (through
extern(C++) interface), override the what(
On Saturday, 27 September 2014 at 09:53:37 UTC, Jacob Carlborg
wrote:
On 2014-09-23 19:37, Andrei Alexandrescu wrote:
We need a libunwind expert to figure out a good approach for
handling
exceptions thrown by C++ code into D.
BTW, are you only interested in handling C++ exception, or are
you
On Thursday, 25 September 2014 at 13:58:23 UTC, Andrei
Alexandrescu wrote:
On 9/25/14, 4:55 AM, Kagamin wrote:
On Wednesday, 24 September 2014 at 15:07:05 UTC, Andrei
Alexandrescu wrote:
I wonder how difficult would be to create a wrapper class
CppException
for everything derived from C++ std:
On Wednesday, 24 September 2014 at 22:14:5 UTC, Andrei
Alexandrescu wrote:
On 9/24/14, 2:53 PM, IgorStepanov wrote:
I have one freaky example for you. This example can be
non-standart and danger but it works:
C++ side: http://pastebin.ru/PceYCOEq
special function catch exception, pass it to spe
Now DMD doesn't support thorowing C++ exceptions through D
function:
extern(C++)
void throwEx(); //compiled by G++ and throws exception
extern(C++)
void dFunc(void*)
{
throwEx();
}
catchException(&dFunc, ...); //terminate programm instead of
catch it. Should be works in gdc
On Wednesday, 24 September 2014 at 19:28:50 UTC, Andrei
Alexandrescu wrote:
On 9/24/14, 9:54 AM, Iain Buclaw via Digitalmars-d wrote:
On 24 September 2014 16:07, Andrei Alexandrescu via
Digitalmars-d
wrote:
I wonder how difficult would be to create a wrapper class
CppException for
everything
On Tuesday, 23 September 2014 at 17:37:42 UTC, Andrei
Alexandrescu wrote:
We need a libunwind expert to figure out a good approach for
handling exceptions thrown by C++ code into D.
Is anyone fluent with libunwind?
Andrei
Is there plans to catching C++ exceptions in D?
What kind of C++ exce
I've created issue about last postblit call optimization (LPO):
https://issues.dlang.org/show_bug.cgi?id=13492
As I wrote in issue description, this optimization can solve 90%
r-value reference issue.
Let's talk about remaining 10%.
There are remain two issue:
1. value argument causes full copyi
The point is that using these enforce() statements means that
these methods cannot be nothrow, which doesn't seem
particularly nice if it can be avoided. Now, on the one hand,
one could say that, quite obviously, these methods cannot
control their input. But on the other hand, it's reasonable
On Thursday, 18 September 2014 at 10:50:31 UTC, monarch_dodra
wrote:
On Thursday, 18 September 2014 at 00:53:40 UTC, Andrei
Alexandrescu wrote:
On 9/17/14, 12:28 PM, IgorStepanov wrote:
I want to place Foo(1) to buckets[nn].key without postblit
call.
Compiler can't help me now, however, I think
On Thursday, 18 September 2014 at 00:53:40 UTC, Andrei
Alexandrescu wrote:
On 9/17/14, 12:28 PM, IgorStepanov wrote:
I want to place Foo(1) to buckets[nn].key without postblit
call.
Compiler can't help me now, however, I think, It can do it
without
language change.
File an enhancement reques
On Wednesday, 17 September 2014 at 15:03:12 UTC, Andrei
Alexandrescu wrote:
On 9/17/14, 3:03 AM, IgorStepanov wrote:
BTW. About r-values:
void fun(S s)
{
fun2(s); //pass s by value.
}
Now, compiler inserts postblit call before func2 call and dtor
before
end of fun.
Is the call to dtor
BTW. About r-values:
void fun(S s)
{
fun2(s); //pass s by value.
}
Now, compiler inserts postblit call before func2 call and dtor
before end of fun. However, it is able to doesn't it, because
after fun2 call, s isn't used.
Thus, we can implement last postblit optimization:
If compiler wan
1 - 100 of 102 matches
Mail list logo
