On 2 September 2016 at 06:09, Marco Leise via Digitalmars-d
wrote:
> Am Wed, 31 Aug 2016 15:58:28 +1000
> schrieb Manu via Digitalmars-d :
>
>> I have this implementation issue, which I'm having trouble applying
>> good judgement, I'd like
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications,
e.g. breaks lots of optimizations b/c you can't know who
accesses sth.
i really HATE modern trend of turning tables. am i the only one
who thinks that the machine was
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
My open PR for the actual inclusion of the
On Friday, 2 September 2016 at 04:43:46 UTC, Uranuz wrote:
code.dlang.org 500 Internal Server Error
Does anyone experience the same probleme?
Yes, its been like this for a few hours at least. It's causing
travis-ci build failures also.
On Friday, 2 September 2016 at 04:43:46 UTC, Uranuz wrote:
code.dlang.org 500 Internal Server Error
Does anyone experience the same probleme?
Unfortunately yes
https://github.com/dlang/dub-registry/issues/174
code.dlang.org 500 Internal Server Error
Does anyone experience the same probleme?
On 02/09/2016 3:25 PM, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for that. While
my work on the precise GC didn't go as planned, it is closer than it was
to be getting merged.
My open PR for the actual inclusion of the precise GC is here:
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
[...]
wait for merge
Hi everyone,
I know I'm super late to the party for this, and sorry for that.
While my work on the precise GC didn't go as planned, it is
closer than it was to be getting merged.
My open PR for the actual inclusion of the precise GC is here:
https://github.com/dlang/druntime/pull/1603
Even
On 02/09/2016 6:01 AM, Basile B. wrote:
I've converted this section:
"configurations" : [
{
"name" : "nux32",
"dflags" : [
"objects/coff32/beaengine.o"
]
},
{
"name" : "nux64",
"dflags" : [
"objects/coff64/beaengine.o"
]
},
On Friday, 2 September 2016 at 01:53:58 UTC, Steven Schveighoffer
wrote:
On 9/1/16 9:27 PM, mogu wrote:
Here's my code in main function:
```
auto fiber = new Fiber({
while (true) {
Thread.sleep(1.seconds);
Fiber.yield;
}
});
void foo() {
On Thu, 01 Sep 2016 18:42:13 +0200, Rory McGuire via Digitalmars-d wrote:
> Thanks, for the GC stub, that will be great for playing with whether or
> not a little dmd app crashes after gc_annihilate(true).
>
> Did I understand that right?
It sounds like this there's a special function
On 9/1/16 9:27 PM, mogu wrote:
Here's my code in main function:
```
auto fiber = new Fiber({
while (true) {
Thread.sleep(1.seconds);
Fiber.yield;
}
});
void foo() {
while (true) {
fiber.call;
https://issues.dlang.org/show_bug.cgi?id=16460
j...@red.email.ne.jp changed:
What|Removed |Added
Keywords||ice
Severity|normal
https://issues.dlang.org/show_bug.cgi?id=16460
Issue ID: 16460
Summary: [REG2.071] ICE in local import for a package
protection func
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Here's my code in main function:
```
auto fiber = new Fiber({
while (true) {
Thread.sleep(1.seconds);
Fiber.yield;
}
});
void foo() {
while (true) {
fiber.call;
//Thread.sleep(1.seconds);
On Thursday, 1 September 2016 at 16:52:41 UTC, Karabuta wrote:
Good write-up. However the font-family and font-size makes
reading a little difficult.
The font family is the same as the rest of dlang.org. As for the
size, what sort of device and resolution are you using? The theme
is a
On Thursday, 1 September 2016 at 16:28:35 UTC, jmh530 wrote:
On Thursday, 1 September 2016 at 15:58:38 UTC, Russel Winder
wrote:
Is there no module in D for statistics functions such as mean,
median,
mode, standard deviation, linear least squares, etc. There are
codes on
Rosetta Code but a)
On 09/01/2016 11:51 PM, Rory McGuire via Digitalmars-d-announce wrote:
Yeah, I'm using an enum to force the evaluation during CT,
I had missed that detail. Still, the error seems to be independent of
any CTFE that's going on.
[...]
Here is another example:
void main() {
enum ret =
On Thursday, 1 September 2016 at 21:48:41 UTC, Rory McGuire wrote:
I was hoping that the error was coming from the CTFE engine as
it ran the code, but it comes up before ctfe execution I guess.
As a general comment, there is no such thing as a CTFE phase. It
is performed in-line with other
On Thu, Sep 01, 2016 at 08:43:16PM +, David Nadlinger via
Digitalmars-d-announce wrote:
> On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote:
> > I have something that will help with that a little bit.
> > https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply
> >
On Thursday, 1 September 2016 at 20:46:50 UTC, Steven
Schveighoffer wrote:
On 8/31/16 5:56 AM, Johan Engelen wrote:
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications,
e.g.
breaks lots of optimizations b/c you can't
On Thu, Sep 1, 2016 at 11:26 PM, ag0aep6g via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> There is no CTFE error in your example.
https://issues.dlang.org/show_bug.cgi?id=16457
greenify changed:
What|Removed |Added
CC||greeen...@gmail.com
On Thu, Sep 1, 2016 at 11:05 PM, David Nadlinger via Digitalmars-d-announce
wrote:
> On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> You can, by using __traits(compiles,
On Thursday, 1 September 2016 at 21:07:36 UTC, Steven
Schveighoffer wrote:
On 9/1/16 4:38 PM, Yuxuan Shui wrote:
[...]
Referring to a null object is not a problem. Your program
crashes ungracefully, but does not corrupt memory. However, in
either approach, it can easily end up being a
On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote:
I'm actually asking why we can't catch the ctfe error.
There is no CTFE error in your example. It doesn't compile in the first
place, even without attempting any CTFE.
[...]
Surely the ctfe engine could be changed to
On Thursday, 1 September 2016 at 20:43:16 UTC, David Nadlinger
wrote:
See also: https://github.com/dlang/dmd/pull/692 – it's about
time we finally got __ctfeWrite() merged.
— David
Oh yeah.
Let me get this into PR shape.
https://issues.dlang.org/show_bug.cgi?id=16458
Lodovico Giaretta changed:
What|Removed |Added
Status|NEW |RESOLVED
On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
I'm actually asking why we can't catch the ctfe error.
You can, by using __traits(compiles, …).
Surely the ctfe engine could be changed to catch unsupported
code errors. (Not invalid, just unsupported at CT).
It already
On 9/1/16 4:38 PM, Yuxuan Shui wrote:
On Thursday, 1 September 2016 at 20:28:03 UTC, Rene Zwanenburg wrote:
On Thursday, 1 September 2016 at 19:37:25 UTC, Yuxuan Shui wrote:
[...]
This will allocate a closure. A struct definition inside a function
has a hidden context / closure pointer,
On Thursday, 1 September 2016 at 20:38:13 UTC, Yuxuan Shui wrote:
I think my approach is probably better, because I believe
(correct me if I'm wrong): 1) it will never refer to a null
object.
That's true, but you can ensure the same thing for the wrapper:
struct Ref()
{
@disable this();
On Thursday, 1 September 2016 at 18:01:19 UTC, Basile B. wrote:
I've converted this section:
[...]
to:
"buildSettings" : {
"dflags-linux-x86" : ["objects/coff32/beaengine.o"],
"dflags-linux-x86_64" : ["objects/coff64/beaengine.o"],
"dflags-windows-x86" :
On 01 Sep 2016 21:36, "David Nadlinger via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
>>
>> So why can't we even catch the Error during CTFE, that would at least
help somewhat.
>
>
> You are mixing
On 8/31/16 5:56 AM, Johan Engelen wrote:
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications, e.g.
breaks lots of optimizations b/c you can't know who accesses sth.
"lots of optimizations"
Can you mention a few?
I'm
On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote:
I have something that will help with that a little bit.
https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln
when you apply this patch __ctfeWriteln() will output every
compiletime avilable string to the console.
More
On Thursday, 1 September 2016 at 18:45:14 UTC, deadalnix wrote:
On Wednesday, 31 August 2016 at 18:50:58 UTC, simendsjo wrote:
An article about how outsourcing reduces the need for
Norwegian developers. No links to D other than the image on
top though. I wonder what they searched for to find
On Thursday, 1 September 2016 at 20:28:03 UTC, Rene Zwanenburg
wrote:
On Thursday, 1 September 2016 at 19:37:25 UTC, Yuxuan Shui
wrote:
[...]
This will allocate a closure. A struct definition inside a
function has a hidden context / closure pointer, unless it's a
static struct.
There is
On Thursday, 1 September 2016 at 19:37:25 UTC, Yuxuan Shui wrote:
I just figured out how to store a reference:
@safe:
auto x(ref int a) {
struct A {
ref int xa() { return a; }
}
return A();
}
void main() {
import std.stdio;
int b = 10;
Am Wed, 31 Aug 2016 15:58:28 +1000
schrieb Manu via Digitalmars-d :
> I have this implementation issue, which I'm having trouble applying
> good judgement, I'd like to survey opinions...
>
> So, RGB colours depend on this 'normalised integer' concept, that is:
>
On Thursday, 1 September 2016 at 17:10:00 UTC, Seb wrote:
FYI: There's some discussion about it's benefit in comparison
to functional language D does have loops and it's a lot easier
to write and read them.
Some are of that opinion. However, this is D, not Python or Go,
so claims about the
On Thursday, 1 September 2016 at 19:32:23 UTC, Timon Gehr wrote:
Well, I'd argue that's not quite right and the correct
interpretation is
"If not the other X then this X", due to the
`!__traits(compiles,
.f!T)`, explicitly telling the compiler to check if the *other*
"overloads" compile.
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
At the moment I just have a verbose logging mode with
pragma(msg) for my
CTFE stuff.
I have something that will help with that a little bit.
https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln
when you apply this patch
I just figured out how to store a reference:
@safe:
auto x(ref int a) {
struct A {
ref int xa() { return a; }
}
return A();
}
void main() {
import std.stdio;
int b = 10;
auto a = x(b);
a.xa = 20;
writeln(b); //Prints
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
So why can't we even catch the Error during CTFE, that would at
least help somewhat.
You are mixing up runtime exceptions ("throw …") with compiler
errors (missing a semicolon). dm.D.learn should be able to help
clear that
On 01.09.2016 21:02, Meta wrote:
On Thursday, 1 September 2016 at 18:24:13 UTC, Timon Gehr wrote:
The idea is that there'd only be one such "fallback" template, so that
you cannot get into a situation such as this. I'm guessing the ICE is
due to a recursive dependency between the two f
On Wednesday, 31 August 2016 at 13:29:52 UTC, Basile B. wrote:
On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe
wrote:
Ugh, it really should just give everything and have getMember
bypass it. That won't even break any code!
you're right. "allMembers" means "all" after all. Another
On Thu, Sep 1, 2016 at 9:09 PM, David Nadlinger via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
>
>> is that in one of the "semantic" passes the compiler has?
>>
>
> For reference, I've laid out the
On Thursday, 1 September 2016 at 17:21:02 UTC, Meta wrote:
I just thought of this, but cannot test if it works. If it
does, maybe it would be a suitable solution?
void f(T)(T t) if(isSomething!T) {}
void f(T)(T t) if(isSomethingElse!T) {}
//Taken if no other "overload" of f will intantiate
On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
is that in one of the "semantic" passes the compiler has?
For reference, I've laid out the reasons why this proposal
couldn't work to Stefan here:
https://github.com/dlang/dmd/pull/6098#issuecomment-243375543
The real
On Thursday, 1 September 2016 at 18:24:13 UTC, Timon Gehr wrote:
The idea is that there'd only be one such "fallback" template,
so that
you cannot get into a situation such as this. I'm guessing the
ICE is
due to a recursive dependency between the two f templates?
I posted the ICE to show
https://issues.dlang.org/show_bug.cgi?id=16455
--- Comment #4 from ag0ae...@gmail.com ---
(In reply to apham from comment #2)
> Based on this https://dlang.org/spec/function.html#closures and the code,
> the struct var is not moving anywhere and not out of scope, so it must work
The NodeRange
On Wednesday, 31 August 2016 at 18:50:58 UTC, simendsjo wrote:
An article about how outsourcing reduces the need for Norwegian
developers. No links to D other than the image on top though. I
wonder what they searched for to find this image.
On Thu, Sep 01, 2016 at 06:11:55PM +, angel via Digitalmars-d wrote:
> If one creates a unittest block in a templated class (or struct), the
> unittest block will be multiplied per class specialization, which
> might turn out to be quite large number.
>
> E.g.
> struct A(T) {
> ...
>
On 01.09.2016 19:55, Meta wrote:
On Thursday, 1 September 2016 at 17:49:13 UTC, Timon Gehr wrote:
On 01.09.2016 19:21, Meta wrote:
...
I just thought of this, but cannot test if it works. If it does, maybe
it would be a suitable solution?
void f(T)(T t) if(isSomething!T) {}
void f(T)(T t)
On Thursday, 1 September 2016 at 18:11:55 UTC, angel wrote:
If one creates a unittest block in a templated class (or
struct), the unittest block will be multiplied per class
specialization, which might turn out to be quite large number.
E.g.
struct A(T) {
...
unittest {
If one creates a unittest block in a templated class (or struct),
the unittest block will be multiplied per class specialization,
which might turn out to be quite large number.
E.g.
struct A(T) {
...
unittest {
...
}
}
...
auto a = A!int;
auto b = A!int;
auto c
I've converted this section:
"configurations" : [
{
"name" : "nux32",
"dflags" : [
"objects/coff32/beaengine.o"
]
},
{
"name" : "nux64",
"dflags" : [
"objects/coff64/beaengine.o"
]
},
{
"name" : "win32",
On Thursday, 1 September 2016 at 17:49:13 UTC, Timon Gehr wrote:
On 01.09.2016 19:21, Meta wrote:
...
I just thought of this, but cannot test if it works. If it
does, maybe
it would be a suitable solution?
void f(T)(T t) if(isSomething!T) {}
void f(T)(T t) if(isSomethingElse!T) {}
//Taken
On 01.09.2016 19:21, Meta wrote:
...
I just thought of this, but cannot test if it works. If it does, maybe
it would be a suitable solution?
void f(T)(T t) if(isSomething!T) {}
void f(T)(T t) if(isSomethingElse!T) {}
//Taken if no other "overload" of f will intantiate with the given T
void
On Thursday, 1 September 2016 at 16:50:49 UTC, Steven
Schveighoffer wrote:
I agree. Note that if(isSomethingElse!T) may also need to have
if(!isSomething!T && isSomethingElse!T).
A suggestion in the past was to allow "else" clauses with if
constraints. I had envisioned:
void f(T)(T t)
On Thursday, 1 September 2016 at 12:04:51 UTC, qznc wrote:
On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
D has a lot to offer with regard to functional programming. It
has pure functions and true immutable classes (true = also sub
objects become immutable), which Scala all
On Thursday, 1 September 2016 at 16:52:41 UTC, Karabuta wrote:
On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote:
Joakim has put together an interview with Walter that's all
about D. It's an enjoyable read. You can parse the interview
at [1] and visit the reddit thread at [2]. I
On 9/1/16 1:37 AM, Manu via Digitalmars-d wrote:
So, consider a set of overloads:
void f(T)(T t) if(isSomething!T) {}
void f(T)(T t) if(isSomethingElse!T) {}
void f(T)(T t) {}
I have a recurring problem where I need a fallback function like the
bottom one, which should be used in lieu of
On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote:
Joakim has put together an interview with Walter that's all
about D. It's an enjoyable read. You can parse the interview at
[1] and visit the reddit thread at [2]. I anticipate publishing
more of Joakim's interviews on the blog in
On Thursday, 1 September 2016 at 16:38:15 UTC, Dicebot wrote:
On 09/01/2016 07:17 PM, ZombineDev wrote:
On Thursday, 1 September 2016 at 12:06:21 UTC, Dicebot wrote:
On 08/31/2016 01:01 PM, Atila Neves wrote:
And never mind that any such low level library would suffer
from the same problem
On Thu, Sep 1, 2016 at 6:29 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
>
>> the _checkCTFE() function is just a function that does something we're not
>> allowed to do at CTFE, but
Thanks, for the GC stub, that will be great for playing with whether or not
a little dmd app crashes after gc_annihilate(true).
Did I understand that right?
R
On Thu, Sep 1, 2016 at 6:16 PM, Cauterite via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Monday, 29 August 2016 at
On 09/01/2016 07:17 PM, ZombineDev wrote:
> On Thursday, 1 September 2016 at 12:06:21 UTC, Dicebot wrote:
>> On 08/31/2016 01:01 PM, Atila Neves wrote:
>>> And never mind that any such low level library would suffer from the
>>> same problem unit-threaded did until dub fixed it: D can't reflect on
On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
the _checkCTFE() function is just a function that does
something we're not
allowed to do at CTFE, but current implementation does not
respect
__traits(compiles, );
As far as I can tell that is a bug. Thoughts?
It is
On Thursday, 1 September 2016 at 15:58:38 UTC, Russel Winder
wrote:
Is there no module in D for statistics functions such as mean,
median,
mode, standard deviation, linear least squares, etc. There are
codes on
Rosetta Code but a) they seem a bit inconsistent in style; and
b) they
are not
On Thursday, 1 September 2016 at 12:06:21 UTC, Dicebot wrote:
On 08/31/2016 01:01 PM, Atila Neves wrote:
And never mind that any such low level library would suffer
from the same problem unit-threaded did until dub fixed it: D
can't reflect on packages so a program must be written that
On Monday, 29 August 2016 at 10:42:23 UTC, Alexander Breckel
wrote:
Because of the poor memory management in the compiler, I included
a modified GC-stub when I compiled the frontend as a library, so
that it can be used in long-running processes:
Is there no module in D for statistics functions such as mean, median,
mode, standard deviation, linear least squares, etc. There are codes on
Rosetta Code but a) they seem a bit inconsistent in style; and b) they
are not in a module available for use.
--
Russel.
On Thu, Sep 01, 2016 at 03:37:50PM +1000, Manu via Digitalmars-d wrote:
> So, consider a set of overloads:
>
> void f(T)(T t) if(isSomething!T) {}
> void f(T)(T t) if(isSomethingElse!T) {}
> void f(T)(T t) {}
>
> I have a recurring problem where I need a fallback function like the
> bottom
nvm. Renaming the MyDigestWrapper import caused the error.
On Thursday, 1 September 2016 at 09:37:22 UTC, Kagamin wrote:
Probably LDC issue https://github.com/ldc-developers/ldc/issues
Thank you for your reply. I built LDC (version 1.1.0 beta 2) from
source and ran dub using:
$ dub run --compiler="~/Downloads/ldc/bin/ldc2"
And everything works
On Thursday, 1 September 2016 at 10:38:07 UTC, qznc wrote:
On Thursday, 1 September 2016 at 10:30:12 UTC, Guillaume Piolat
wrote:
On Thursday, 1 September 2016 at 07:46:04 UTC, qznc wrote:
I find the documentation on MemoryOrder lacking about the
semantics of rel. :(
[0]
I didn't see your announcement, but... AWESOME!!
This could be the basis for some really good tutorials on making compiler
backends etc...
We need more little teaser examples like the one you posted in the
beginning of this thread.
PS: I did already check the code out on github because I watch
Hello all,
I'm trying to use a std.digest, namely MD5 and sHA, as a
template parameter like so:
auto x = new MyDigestWrapper!MD5;
The compiler (dmd2) then throws two error messages at me which
puzzle me.
phobos/std/traits.d 554: Error: forward reference of variable
parentPrefix, and
https://issues.dlang.org/show_bug.cgi?id=16459
Issue ID: 16459
Summary: opDispatch gives obtuse error when dispatching to a
function that doesn't exist
Product: D
Version: D2
Hardware: x86_64
OS: Windows
On Wed, Aug 31, 2016 at 10:43 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote:
>
>> On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
>>
>>> I just came up with a nifty little patch
On Thursday, 1 September 2016 at 10:37:18 UTC, Miguel L wrote:
Also, forgot to specify I am using LDC with -05.
And the version of LDC too please ;-)
On Thursday, 1 September 2016 at 08:46:07 UTC, Stefan Koch wrote:
On Thursday, 1 September 2016 at 08:44:38 UTC, Stefan Koch
wrote:
void f(T)(T t) {
static if (is(fImpl(t) == void)) {
f(t);
} else {
// default impl here
}
}
Was meant to be
void f(T)(T t) {
static if
On 08/31/2016 01:01 PM, Atila Neves wrote:
> And never mind that any such low level library would suffer from the
> same problem unit-threaded did until dub fixed it: D can't reflect on
> packages so a program must be written that explicitly lists all modules
> that need to be looked at.
I don't
On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
D has a lot to offer with regard to functional programming. It
has pure functions and true immutable classes (true = also sub
objects become immutable), which Scala all doesn't have
(because of restrictions of the JVM). Does D have
On 08/30/2016 10:40 PM, Jacob Carlborg wrote:
> On 2016-08-30 18:31, Dicebot wrote:
>
>> I definitely wouldn't want to use API like you proposed if I was to
>> write my own test runner. Minimal common ground which would be cool to
>> have is getting range/array of all unittest blocks together
On Thursday, 1 September 2016 at 11:34:28 UTC, Basile B. wrote:
On Thursday, 1 September 2016 at 11:09:18 UTC, slaid wrote:
I have a snippet:
How do I override this height field?
Thanks
The field height is not overridden. In C you have two "height".
Since your array is of type A[], map
On 08/31/2016 04:44 PM, Ethan Watson wrote:
> http://dlang.org/deprecate.html#typedef
>
> "typedef is not flexible enough to cover all use cases. This is better
> done with a library solution."
>
> [Citation needed]
>
> What use cases is it not flexible enough for?
It has unadjustable
On 08/31/2016 02:08 AM, Martin Nowak wrote:
> On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
>> I'm a bit sad to see that
>> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored
>> to fix issue 15907. Another decision could have been to break the
>> visibility for
On Thursday, 1 September 2016 at 11:01:28 UTC, Dominikus Dittes
Scherkl wrote:
Ok, that may be fine, until you reach the point with the
fallback version: if after that point someone "drops in" a new
version, he silently changes the behavior of the function,
because he "steals" some type which
On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote:
So, consider a set of overloads:
void f(T)(T t) if(isSomething!T) {}
void f(T)(T t) if(isSomethingElse!T) {}
void f(T)(T t) {}
I have a recurring problem where I need a fallback function
like the bottom one, which should be used
On Thursday, 1 September 2016 at 11:09:18 UTC, slaid wrote:
I have a snippet:
How do I override this height field?
Thanks
The field height is not overridden. In C you have two "height".
Since your array is of type A[], map takes A.height.
abstract class A
{
int height = 0;
}
class B
On Thursday, 1 September 2016 at 10:50:18 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes
Scherkl wrote:
I have never seen what benefit could be gained from having
overloads. I think they are a relict from languages without
static if.
I
On 1 September 2016 at 20:43, Dominikus Dittes Scherkl via
Digitalmars-d wrote:
> On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote:
>>
>> Consider that more overloads are being introduced by users spread out
>> across many modules that define their own kind
On 01/09/2016 11:11 PM, Cauterite wrote:
How does one test whether a symbol is deprecated? I would have expected
something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not accessible in
any way from code?
The only solution I can think of is compiling
How does one test whether a symbol is deprecated? I would have
expected something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not
accessible in any way from code?
The only solution I can think of is compiling with -de and using
__traits(compiles,
I have a snippet:
import std.stdio;
import std.algorithm;
abstract class A {
int height = 0;
}
class B : A {
}
class C : A {
int height = 1;
}
void main() {
A[][int] list;
list[0] = new A[](0);
list[0] ~= new B();
list[0] ~= new C();
On Thursday, 1 September 2016 at 10:53:01 UTC, Ethan Watson wrote:
On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes
Scherkl wrote:
I have never seen what benefit could be gained from having
overloads.
Oh, it's perfectly fine if you're not writing a library that's
designed to
On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes
Scherkl wrote:
I have never seen what benefit could be gained from having
overloads.
Oh, it's perfectly fine if you're not writing a library that's
designed to allow user extension by going the "all in one"
method. If you
1 - 100 of 127 matches
Mail list logo