On Monday, 25 August 2014 at 06:27:00 UTC, Shachar wrote:
The following program compiles, and does what you'd expect:
struct A {
int a;
}
pure int func( ref A a )
{
return a.a += 3;
}
As far as I can tell, however, it shouldn't. I don't see how or
why func can possibly be considered p
The following program compiles, and does what you'd expect:
struct A {
int a;
}
pure int func( ref A a )
{
return a.a += 3;
}
As far as I can tell, however, it shouldn't. I don't see how or
why func can possibly be considered pure, as it changes a state
external to the function.
Wha
On Mon, 25 Aug 2014 01:14:19 +
Aerolite via Digitalmars-d-learn
wrote:
> I just can't help but think that really, such a feature should be
> at the language level.
this is the first topic about multiple-dispatch in at least... eh... 6
months (maybe more). chances that it will be included in c
On 8/25/2014 11:35 AM, Vladimir Panteleev wrote:
On Monday, 25 August 2014 at 02:17:47 UTC, Mike Parker wrote:
// Put this somewhere you can import it into any module calling
Small modification for even terser error handling:
T sdlEnforce(T)(T result, string message = null)
{
if (!result)
On Monday, 25 August 2014 at 02:17:47 UTC, Mike Parker wrote:
// Put this somewhere you can import it into any module calling
Small modification for even terser error handling:
T sdlEnforce(T)(T result, string message = null)
{
if (!result)
throw new SdlException("SDL error: "
~ (m
On 8/23/2014 7:19 PM, nikki wrote:
How would you write it?
```
// Put this somewhere you can import it into any module calling SDL
class SDLError : Error {
public this( string msg, string file = __FILE__, size_t line =
__LINE__ ) {
import std.string;
import std.conv;
On Monday, 25 August 2014 at 01:34:14 UTC, Idan Arye wrote:
On Monday, 25 August 2014 at 01:10:32 UTC, Aerolite wrote:
-- No syntax modification (unless you want the feature to be
optional)
If this ever gets into the core language, it absolutely must be
optional! Think of the implications of
On Monday, 25 August 2014 at 01:10:32 UTC, Aerolite wrote:
-- No syntax modification (unless you want the feature to be
optional)
If this ever gets into the core language, it absolutely must be
optional! Think of the implications of having this as the default
and only behavior:
* Every ove
On Monday, 25 August 2014 at 00:42:41 UTC, Idan Arye wrote:
Speaking of library solutions, I checked with my `castSwitch`
PR and it managed to implement single-argument multi-dispatch:
https://github.com/D-Programming-Language/phobos/pull/1266#issuecomment-53217374
I'll try to get it to suppor
On Monday, 25 August 2014 at 00:08:25 UTC, Jonathan M Davis wrote:
At this point, if something can be implemented in a library
rather than in the language, the odds are low that it will be
solved in the language. The language is very powerful and
already a bit complicated, so usually the resp
On Monday, 25 August 2014 at 00:20:26 UTC, Vladimir Panteleev
wrote:
On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
So what seems to be the situation here?
Hi Aerolite,
I've never used multiple dispatch in any language, but from
looking at the C# syntax here[1]:
ReactSpecializ
On Monday, 25 August 2014 at 00:36:40 UTC, Vladimir Panteleev
wrote:
On Monday, 25 August 2014 at 00:20:26 UTC, Vladimir Panteleev
wrote:
dynamic!ReactSpecialization(me, other);
Here's a very basic implementation:
http://dpaste.dzfl.pl/5150ca9c13f4
Idan Arye is also working on functional pat
On Sunday, 24 August 2014 at 21:54:57 UTC, jicman wrote:
On Sunday, 24 August 2014 at 10:52:38 UTC, bearophile wrote:
jicman:
This is line 7634:
const Size DEFAULT_SCALE = { 5, 13 };
What does the error say and how can I fix it? Thanks.
Can you show the (reduced) definition of Size and
D
On Monday, 25 August 2014 at 00:08:25 UTC, Jonathan M Davis wrote:
On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
Hey all,
I was surprised to learn yesterday that D does not actually
support Multiple-Dispatch, also known as Multimethods. Why is
this? Support for this feature is alre
On Monday, 25 August 2014 at 00:20:26 UTC, Vladimir Panteleev
wrote:
dynamic!ReactSpecialization(me, other);
Here's a very basic implementation:
http://dpaste.dzfl.pl/5150ca9c13f4
Idan Arye is also working on functional pattern matching for
object references:
https://github.com/D-Programmi
On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
So what seems to be the situation here?
Hi Aerolite,
I've never used multiple dispatch in any language, but from
looking at the C# syntax here[1]:
ReactSpecialization(me as dynamic, other as dynamic);
You should be able to implem
Aerolite:
I was surprised to learn yesterday that D does not actually
support Multiple-Dispatch, also known as Multimethods. Why is
this? Support for this feature is already present in Scala, C#
4.0, Groovy, Clojure, etc... Would it not make sense for D to
remain competitive in this regard?
I
On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
Hey all,
I was surprised to learn yesterday that D does not actually
support Multiple-Dispatch, also known as Multimethods. Why is
this? Support for this feature is already present in Scala, C#
4.0, Groovy, Clojure, etc... Would it not m
Ola Fosheim Grøstad:
Bearophile has created many such examples at Rosettacode.
I am updating and improving them, but I have created only a
percentage of them (60-70%? I don't know).
Bye,
bearophile
Hey all,
I was surprised to learn yesterday that D does not actually
support Multiple-Dispatch, also known as Multimethods. Why is
this? Support for this feature is already present in Scala, C#
4.0, Groovy, Clojure, etc... Would it not make sense for D to
remain competitive in this regard?
While
On Sunday, 24 August 2014 at 23:36:55 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 24 August 2014 at 23:20:21 UTC, maik klein wrote:
It's actually quite strange that no one has done something
like this in D, it's usually the first thing people do.
Bearophile has created many such examples at Ros
On Sunday, 24 August 2014 at 23:20:21 UTC, maik klein wrote:
It's actually quite strange that no one has done something like
this in D, it's usually the first thing people do.
Bearophile has created many such examples at Rosettacode.
On Sunday, 24 August 2014 at 21:51:39 UTC, Weaseldog wrote:
On Sunday, 24 August 2014 at 20:32:02 UTC, maik klein wrote:
Are there any exercises/challenges for D?
Something like this?
http://www.haskell.org/haskellwiki/99_questions/1_to_10
Well, you could port 99 lisp problems to D - D can b
On Sunday, 24 August 2014 at 20:32:02 UTC, maik klein wrote:
Are there any exercises/challenges for D?
Something like this?
http://www.haskell.org/haskellwiki/99_questions/1_to_10
Well, you could port 99 lisp problems to D - D can be written in
a fairly functional style ;)
On Sunday, 24 August 2014 at 10:52:38 UTC, bearophile wrote:
jicman:
This is line 7634:
const Size DEFAULT_SCALE = { 5, 13 };
What does the error say and how can I fix it? Thanks.
Can you show the (reduced) definition of Size and
DEFAULT_SCALE? Even better to show a minimized self-contain
maik klein:
Are there any exercises/challenges for D?
Something like this?
http://www.haskell.org/haskellwiki/99_questions/1_to_10
This is an interesting question. There are many
exercises/challenges that can be done in D, but I don't know any
specific for D. As D challenge I suggest to wr
Are there any exercises/challenges for D?
Something like this?
http://www.haskell.org/haskellwiki/99_questions/1_to_10
On Sun, 24 Aug 2014 19:23:01 +
Stefan Frijters via Digitalmars-d-learn
wrote:
> request I do have a followup question: is it possible somehow to
> have both a @nogc and a normal opApply function available?
you can use templated opApply():
import std.traits;
struct NumberRange {
i
On Sunday, 24 August 2014 at 18:55:09 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sun, 24 Aug 2014 11:45:14 -0700
Ali Çehreli via Digitalmars-d-learn
wrote:
Yeah, the only reason why the original code does not work is
the
write() expression in the foreach body.
hm. really. i forgot what i
On 08/24/2014 09:03 PM, simendsjo wrote:
> I don't know the arguments for my process before reading some of stdin.
> I was thinking I could solve this by creating a temporary file as a
> "stdin buffer" while I found out the correct argument and could launch
> the process. Unfortunately, this fails.
I don't know the arguments for my process before reading some of stdin.
I was thinking I could solve this by creating a temporary file as a
"stdin buffer" while I found out the correct argument and could launch
the process. Unfortunately, this fails.
Error: 'object.Exception@std/stdio.d(2070): Enf
On Sun, 24 Aug 2014 11:45:14 -0700
Ali Çehreli via Digitalmars-d-learn
wrote:
> Yeah, the only reason why the original code does not work is the
> write() expression in the foreach body.
hm. really. i forgot what is delegate body for opApply. sure, here we
can't use @nogc delegate. my fault.
si
On 08/24/2014 06:40 AM, ketmar via Digitalmars-d-learn wrote:
> On Sun, 24 Aug 2014 13:22:49 +
> Stefan Frijters via Digitalmars-d-learn
> wrote:
>
> @nogc is a part of signature. gc-function can't call @nogc-one. the
> same is with calling @system function from @safe one, for example. or
>
On Sun, 24 Aug 2014 20:29:14 +0200
simendsjo via Digitalmars-d-learn
wrote:
> Talk about confusing. If I want something from pure C libraries, I
> would use core.stdc.
dunno why std.stdio does this public import. i see no sense in it, but
maybe someone with more expirience knows the answer.
sig
On 08/24/2014 08:09 PM, anonymous wrote:
> On Sunday, 24 August 2014 at 17:55:05 UTC, simendsjo wrote:
>> Using DMD 2.066 on GNU/Linux x86_64.
>>
>> This is strange:
>>
>> import std.stdio;
>> void main() {
>> auto f = tmpfile();
>> pragma(msg, typeof(f)); // shared(_IO_FILE)*
>> }
>>
>> Bu
On Sun, 24 Aug 2014 19:56:24 +0200
simendsjo via Digitalmars-d-learn
wrote:
> What is going on here?
std.stdio does this: 'public import core.stdc.stdio'.
and in core.stdc.stdio we can find this:
@trusted FILE* tmpfile();
and FILE as an alias for shared(_IO_FILE), declared in
'core.stdc.stdio' to
On Sunday, 24 August 2014 at 17:55:05 UTC, simendsjo wrote:
Using DMD 2.066 on GNU/Linux x86_64.
This is strange:
import std.stdio;
void main() {
auto f = tmpfile();
pragma(msg, typeof(f)); // shared(_IO_FILE)*
}
But stdio.d looks like the following:
static File tmpfile() @safe
Wh
On 08/24/2014 07:56 PM, simendsjo wrote:
> Using DMD 2.066 on GNU/Linux x86_64.
>
> This is strange:
>
> import std.stdio;
> void main() {
> auto f = tmpfile();
> pragma(msg, typeof(f)); // shared(_IO_FILE)*
> }
>
> But stdio.d looks like the following:
> static File tmpfile() @safe
Using DMD 2.066 on GNU/Linux x86_64.
This is strange:
import std.stdio;
void main() {
auto f = tmpfile();
pragma(msg, typeof(f)); // shared(_IO_FILE)*
}
But stdio.d looks like the following:
static File tmpfile() @safe
What is going on here?
On Sunday, 24 August 2014 at 14:34:03 UTC, bearophile wrote:
ketmar:
but i tend not to fill enhancement requests without
corresponding patches,
I agree that having a patch ready is much better. But people
like me file hundreds of ERs without too much damage done, and
many of them get eventu
On Sun, 24 Aug 2014 08:02:40 -0700
"H. S. Teoh via Digitalmars-d-learn"
wrote:
> Some of us regularly comb through old bugzilla issues to find things
> to test & fix. It may take a long time, but we do try. :-)
>
> (And we could use a lot of help -- there are only a few of us and a
> ton of old
ketmar:
so it can be forgotten in Bugzilla. ;-)
And in ten, or one hundred or one thousand years the whole D
language will be forgotten. There are various levels of
remembering and forgetting. Putting bugs and ERs in databases is
a different kind of forgetting.
Bye,
bearophile
On Sun, Aug 24, 2014 at 05:49:29PM +0300, ketmar via Digitalmars-d-learn wrote:
> On Sun, 24 Aug 2014 14:34:02 +
> bearophile via Digitalmars-d-learn
> wrote:
>
> > putting this information in Bugzilla is better than letting this
> > get forgotten.
> so it can be forgotten in Bugzilla. ;-)
On Sun, 24 Aug 2014 14:34:02 +
bearophile via Digitalmars-d-learn
wrote:
> putting this information in Bugzilla is better than letting this
> get forgotten.
so it can be forgotten in Bugzilla. ;-)
signature.asc
Description: PGP signature
ketmar:
but i tend not to fill enhancement requests without
corresponding patches,
I agree that having a patch ready is much better. But people like
me file hundreds of ERs without too much damage done, and many of
them get eventually implemented. If you find a D limitation, then
putting th
On Sun, 24 Aug 2014 13:58:45 +
bearophile via Digitalmars-d-learn
wrote:
> > there is currenly no way to specify attributes for such implicit
> > delegates.
> It could be a nice language enhancement.
i agree. but i tend not to fill enhancement requests without
corresponding patches, and i'm n
ketmar:
there is currenly no way to specify attributes for such implicit
delegates.
It could be a nice language enhancement.
Bye,
bearophile
On Sun, 24 Aug 2014 13:22:49 +
Stefan Frijters via Digitalmars-d-learn
wrote:
@nogc is a part of signature. gc-function can't call @nogc-one. the
same is with calling @system function from @safe one, for example. or
impure function from pure.
so to say, foreach() creates implicit delegate wi
On 2014-08-24 14:18, Kagamin wrote:
Shouldn't emplace and destroy infer their attributes instead of strictly
annotating them as nogc.
If they are templates, I guess they should. I don't know how good the
compiler is at inferring attributes. I also haven't looked at the source
code for these
Should this be possible? I admit to not being fully clear on the
way delegates are handled, but maybe someone can shed some light?
As an example I use a snippet Ali uses to demonstrate opApply:
struct NumberRange {
int begin;
int end;
int opApply(int delegate(ref int) @nogc operations) @
On Sunday, 24 August 2014 at 02:53:41 UTC, Damian Day wrote:
isImplicitlyConvertible!(ElementType!R, T))
Try [ElementEncodingType][0].
[0]: http://dlang.org/phobos/std_range.html#ElementEncodingType
On Sunday, 24 August 2014 at 11:56:44 UTC, nikki wrote:
I come from languages that don't offer structs, I have this
json load function that has to keep some data and intuitively
I've written a struct, I've read about the differences, heap vs
stack, value vs reference, but know I think i am over
On Sun, 24 Aug 2014 11:56:42 +
nikki via Digitalmars-d-learn wrote:
> Or should I use a class for that AtlasSpriteData?
> reading about it I get the impression everytime I'll look up data
> from that dictionary data will get copied ?
p.s.
this will not copy:
auto sd = "mysprite00" in dic
On Sun, 24 Aug 2014 11:56:42 +
nikki via Digitalmars-d-learn wrote:
> Or should I use a class for that AtlasSpriteData?
> reading about it I get the impression everytime I'll look up data
> from that dictionary data will get copied ?
this will copy:
auto sd = dict[0];
this will copy:
On Sunday, 24 August 2014 at 11:56:44 UTC, nikki wrote:
I come from languages that don't offer structs, I have this
json load function that has to keep some data and intuitively
I've written a struct, I've read about the differences, heap vs
stack, value vs reference, but know I think i am over
On Sunday, 24 August 2014 at 09:29:53 UTC, Jacob Carlborg wrote:
On 2014-08-24 10:03, Bienlein wrote:
I have omitted the code for the TestClass class to save space.
Problem
is that the compiler outputs this:
Error: @nogc function 'main.nogcNew!(TestClass, ).nogcNew'
cannot call
non-@nogc fu
Bienlein:
@nogc is meant mostly for stack-allocation.
Ah, I missed that. Thanks for telling me.
@nogc is also for allocation from the C heap, despite this is
less common :-)
Bye,
bearophile
On 24/08/2014 11:56 p.m., nikki wrote:
I come from languages that don't offer structs, I have this json load
function that has to keep some data and intuitively I've written a
struct, I've read about the differences, heap vs stack, value vs
reference, but know I think i am overthinking it.
Here
I come from languages that don't offer structs, I have this json
load function that has to keep some data and intuitively I've
written a struct, I've read about the differences, heap vs stack,
value vs reference, but know I think i am overthinking it.
Is this decent:
bool loadFromFile
jicman:
This is line 7634:
const Size DEFAULT_SCALE = { 5, 13 };
What does the error say and how can I fix it? Thanks.
Can you show the (reduced) definition of Size and DEFAULT_SCALE?
Even better to show a minimized self-contained program that has
the problem.
Bye,
bearophile
On Sunday, 24 August 2014 at 02:53:41 UTC, Damian Day wrote:
Hi, I've been trying to reduce a bug in the containers (8824).
From the example below it seems the dup method is passing the
constructor
an array of dchars and the template is failing.
Is this a compiler bug, or ?
import std.range,
Mybe, some fields in Size overlap. If you look at it, you may
understand, what happens.
On Sunday, 24 August 2014 at 08:48:03 UTC, bearophile wrote:
Bienlein:
things in such Limbo for several years).
decades
On 2014-08-24 10:03, Bienlein wrote:
I have omitted the code for the TestClass class to save space. Problem
is that the compiler outputs this:
Error: @nogc function 'main.nogcNew!(TestClass, ).nogcNew' cannot call
non-@nogc function 'core.exception.onOutOfMemoryError'
Error: @nogc function 'mai
On Sunday, 24 August 2014 at 08:48:03 UTC, bearophile wrote:
Perhaps there are ways, but note that @nogc is meant mostly for
stack-allocation.
Ah, I missed that. Thanks for telling me. I changed nogcDel now
to null out the deallocated object:
void nogcDel(T)(ref T obj)
{
import core.std
Bienlein:
Is there a way to get around this?
Perhaps there are ways, but note that @nogc is meant mostly for
stack-allocation.
In general when in D you have to write lot of hairy code to do
something, it means that in most cases you shouldn't do that
something.
When calling delete t the
Hello,
I was having a look at the new nogc annotation and therefore
wrote some code that creates an instance on the heap bypassing
the GC (code adapted from http://dpaste.dzfl.pl/2377217c7870).
Problem is that calls to call the class' constructor, destructor
and others can't be called anymore
67 matches
Mail list logo
