Hello,
ich habe a pure method bar() in a class Foo:
class Foo {
int i = 0;
void bar() pure {
i++;
}
}
main() {
auto foo = new Foo();
foo.bar()
}
The pure method bar changes the inst var i. Nevertheless, the
code above c
On Monday, 16 September 2013 at 06:47:40 UTC, ilya-stromberg
wrote:
On Sunday, 15 September 2013 at 18:31:40 UTC, simendsjo wrote:
On Sunday, 15 September 2013 at 17:34:06 UTC, matovitch wrote:
Hi everyone,
I read the documentation about user defined attributes, but I
don't see their uses. Ok
On Monday, 16 September 2013 at 07:01:52 UTC, Bienlein wrote:
Hello,
ich habe a pure method bar() in a class Foo:
class Foo {
int i = 0;
void bar() pure {
i++;
}
}
main() {
auto foo = new Foo();
foo.bar()
}
The pure me
Mark all parameters const to get a strong pure function. For
"this" const goes on the method:
class Foo {
int i = 0;
void bar() const pure {
// can't mutate i here
}
}
See also: http://dlang.org/function.html#pure-functions
I see, thanks a lot. I l
What with all the IDE discussion going on, I thought I'd have a go at trying out
Eclipse with the DDT plugin.
I'm running Eclipse 3.8 installed from system repos on Ubuntu 13.10. Adding the
DDT plugin as per the instructions here:
http://code.google.com/p/ddt/wiki/Installation
... seems to w
All your examples are great, thank you ! Is there a way to omit
validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@nonNull C c) {
...
};
C c;
fun(c); //compilation error since C is null
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to omit
validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@nonNull C c) {
...
};
C c;
fun(c); //compilation error since
I think you are not aswering his question (but maybe I am wrong).
If you want a Fourier transform with less frequencies than
temporal samples you can perform a fft to get a result of same
length like this :
9 2 7 6 1 8 (amplitude)
0 2 4 6 8 10 (frequency)
Then transform it like this :
11 1
On Monday, 16 September 2013 at 10:36:16 UTC, Bienlein wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to
omit validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@non
On 2013-09-16 11:56, Joseph Rushton Wakeling wrote:
What with all the IDE discussion going on, I thought I'd have a go at
trying out Eclipse with the DDT plugin.
I'm running Eclipse 3.8 installed from system repos on Ubuntu 13.10.
Adding the DDT plugin as per the instructions here:
http://code.g
On Saturday, 14 September 2013 at 13:10:54 UTC, simendsjo wrote:
Compiling with --build=unittest and debug works, but not
--build=release:
$ dub build --build=debug
Checking dependencies in 'C:\code\d\myapp'
Building configuration "application", build type debug
Copying files...
Running dmd (co
On 16/09/13 12:58, Jacob Carlborg wrote:
I think it's better that you manually add paths to the compiler, then searching
for it, if possible,
Seems like it's a known issue: http://code.google.com/p/ddt/issues/detail?id=10
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to omit
validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@nonNull C c) {
...
};
C c;
fun(c); //compilation error since
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to
omit validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@
On Monday, September 16, 2013 10:08:22 anonymous wrote:
> Mark all parameters const to get a strong pure function. For
> "this" const goes on the method:
That's not actually enough. At present, in order for a function to be
considered strongly pure, all of its parameters must be either immutable
On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to
omit validate such that the compiler wou
On Monday, 16 September 2013 at 16:50:43 UTC, Namespace wrote:
On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin
wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank y
On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
Ideally structs should have default constructors (hello to
those who miss them - problem #2) which could initialize class
instance.
Do you know why D structs don't have default constructors? I
really miss.
On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
On Monday, 16 September 2013 at 16:50:43 UTC, Namespace wrote:
On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin
wrote:
On Monday, 16 September 2013 at 10
On Monday, 16 September 2013 at 18:44:25 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
Ideally structs should have default constructors (hello to
those who miss them - problem #2) which could initialize class
instance.
Do you know why D structs do
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to omit
validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@nonNull C c) {
...
};
C c;
fun(c); //compilation error since
On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
[...]
> I hate this NotNull struct hack. It is the same crap as the current
> scope solution. BTW: I'm curious which built-in feature will be
> removed next, maybe AA?
[...]
That wouldn't be a bad idea, actually. The current AA implementat
Long time not heard from each other. ;)
On Monday, 16 September 2013 at 19:28:22 UTC, Andrei Alexandrescu
wrote:
On 9/16/13 11:56 AM, Namespace wrote:
I hate this NotNull struct hack. It is the same crap as the
current
scope solution.
Scoped variables in the language were a lot worse.
Why?
On 9/16/13 11:56 AM, Namespace wrote:
I hate this NotNull struct hack. It is the same crap as the current
scope solution.
Scoped variables in the language were a lot worse.
BTW: I'm curious which built-in feature will be removed
next, maybe AA?
If we're diligent and lucky, hopefully.
An a
On Monday, 16 September 2013 at 19:28:22 UTC, Andrei Alexandrescu
wrote:
On 9/16/13 11:56 AM, Namespace wrote:
And I agree absolute, to disable default CTor's by struct's
was a huge
mistake. But D is full of those. ;)
They are not disabled. It seems many people are having trouble
with gettin
On Mon, Sep 16, 2013 at 12:28:21PM -0700, Andrei Alexandrescu wrote:
> On 9/16/13 11:56 AM, Namespace wrote:
> >I hate this NotNull struct hack. It is the same crap as the current
> >scope solution.
>
> Scoped variables in the language were a lot worse.
One thing I'd *really* like to have is prop
On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
[...]
I hate this NotNull struct hack. It is the same crap as the
current
scope solution. BTW: I'm curious which built-in feature will be
removed next, maybe AA?
[...]
Th
On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
Why should anyone switch to D if it is nothing else as a new
C++?
It's worth pointing out that the library AAs proposed here would
still have the same syntax as the built-in ones now.
int[string] a;
would just be magically rewr
On Monday, 16 September 2013 at 20:15:26 UTC, Namespace wrote:
On Monday, 16 September 2013 at 20:09:53 UTC, Adam D. Ruppe
wrote:
On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
Why should anyone switch to D if it is nothing else as a new
C++?
It's worth pointing out that the
On Monday, 16 September 2013 at 20:09:53 UTC, Adam D. Ruppe wrote:
On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
Why should anyone switch to D if it is nothing else as a new
C++?
It's worth pointing out that the library AAs proposed here
would still have the same syntax as t
Ali Çehreli wrote:
> Could you please provide complete code.
Sure. This is of course stripped down just for demonstration purposes:
struct Attr {
string name;
}
mixin template Model() {
static string[string] columns () {
string[string] cols;
alias type = typeof(this);
// Basica
On Monday, 16 September 2013 at 20:16:45 UTC, Namespace wrote:
And maybe also for delete: we need something to delete the
memory manually.
And we need built-in memory allocators, not only GC.
Reduced:
//
module A;
alias fun = Impl!int;
private template Impl(T)
{
void Impl(){}
}
//
void main()
{
fun();
}
//
Error: function A.Impl!int.Impl is not accessible from module main
//
I'm trying to implement a set of public funtions, in terms of a
template. Said temp
On 09/16/13 22:38, Namespace wrote:
>> [1] Obviously, not a practical short term option for the existing D2
>> language.
>> That's probably clear from the context, and the question was meant to be
>> rhetorical -- but it could actually be done and would make sense; it's
>> just
>> not
On Monday, 16 September 2013 at 21:11:00 UTC, Artur Skawina wrote:
On 09/16/13 22:52, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote:
D is not only about arrays.
It's a big plus. ;)
[1] Obviously, not a practical short term option for the
existing D2
language.
On Monday, 16 September 2013 at 20:53:18 UTC, Namespace wrote:
On Monday, 16 September 2013 at 20:43:01 UTC, Aleksey wrote:
I get strange type errors in the following code, and I don't
understand why =( Could anybody help?
struct I {
int i;
I opBinary(string op)(ref I that)
if (o
Kenji Hara wrote:
> Currently this is not a bug.
>
> Looking from the module 'main', the mixin identifier 'X' declared
> in main.d is *closer* than the 'X' declared in aux.d, because the
> latter exists beyond the module import boundary.
> Therefore, the use of 'X' in main.d would prefere the `mix
On Monday, 16 September 2013 at 20:43:01 UTC, Aleksey wrote:
I get strange type errors in the following code, and I don't
understand why =( Could anybody help?
struct I {
int i;
I opBinary(string op)(ref I that)
if (op == "+") {
return I(i + that.i);
}
}
void m
D is not only about arrays.
It's a big plus. ;)
[1] Obviously, not a practical short term option for the
existing D2 language.
That's probably clear from the context, and the question
was meant to be
rhetorical -- but it could actually be done and would make
sense; it's just
not
On 09/16/13 22:52, H. S. Teoh wrote:
> On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote:
>>> D is not only about arrays.
>> It's a big plus. ;)
>>
>>
>>> [1] Obviously, not a practical short term option for the existing D2
>>> language. That's probably clear from the context, and the ques
I get strange type errors in the following code, and I don't
understand why =( Could anybody help?
struct I {
int i;
I opBinary(string op)(ref I that)
if (op == "+") {
return I(i + that.i);
}
}
void main() {
auto a = I(1);
auto d = a + (a + a);
}
Er
On 09/16/13 21:58, Namespace wrote:
> On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
>> On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
>> [...]
>>> I hate this NotNull struct hack. It is the same crap as the current
>>> scope solution. BTW: I'm curious which built-in fe
On Monday, 16 September 2013 at 21:01:48 UTC, Aleksey wrote:
On Monday, 16 September 2013 at 20:53:18 UTC, Namespace wrote:
On Monday, 16 September 2013 at 20:43:01 UTC, Aleksey wrote:
I get strange type errors in the following code, and I don't
understand why =( Could anybody help?
struct I {
On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote:
> >D is not only about arrays.
> It's a big plus. ;)
>
>
> >[1] Obviously, not a practical short term option for the existing D2
> >language. That's probably clear from the context, and the question
> >was meant to be rhetorical -- but i
On Mon, Sep 16, 2013 at 10:59:10PM +0200, Artur Skawina wrote:
> On 09/16/13 22:38, Namespace wrote:
> >> [1] Obviously, not a practical short term option for the existing
> >> D2 language. That's probably clear from the context, and the
> >> question was meant to be rhetorical -- but it c
On Monday, 16 September 2013 at 21:00:21 UTC, monarch_dodra wrote:
I'm trying to implement a set of public funtions, in terms of a
template. Said template has no business being know to the user,
so I want to mark it as private. Unfortunately, if I do this,
then I can't use the alias, because "I
On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
[...]
I hate this NotNull struct hack. It is the same crap as the
current
scope solution. BTW: I'm curious which built-in feature will be
removed next, maybe AA?
[...]
Th
On Monday, 16 September 2013 at 23:53:14 UTC, Meta wrote:
So you're really directly accessing a private symbol. Perhaps a
workaround could be something like this:
//
module Test;
static const fun = &Impl!int;
private template Impl(T)
{
void Impl(){}
}
//
module main;
import Test;
v
On 2013-09-16 22:15, Namespace wrote:
Then of course I have not said anything.
The same thing I would suggest for scope. It exists as a library
solution and is rewritten magical.
I think the big difference here is that AA's are safe where "scope" is
not. I agree with you, I like to use "scope
On 2013-09-17 00:53, H. S. Teoh wrote:
Hmm. I find D arrays just fine the way they are, actually. (In fact, I
rather *liked* the way D arrays worked as compared with, say, C/C++.)
What's wrong with them?
I guess one can complain about some of the built-in
properties/functions, like sort.
--
50 matches
Mail list logo
