On Thursday, 21 August 2014 at 20:16:33 UTC, anonymous wrote:
Maybe you can explain what you're trying to achieve with all
this. There may be a different/better way to do it.
Sure.
Class tree: GameObject->Component->Sprite.
GameObject structure:
Component[];
Component addComponent(Compo
On Thursday, 21 August 2014 at 20:05:13 UTC, Ary Borenszweig
wrote:
I'll tell you how it's done in Crystal in case someone wants to
come up with a proposal to make it work in D.
~~~
class Foo
macro inherited
def method_in_{{@class_name.downcase.id}}
puts "Hello {{@class_name.id}}!"
On Thursday, 21 August 2014 at 19:58:18 UTC, MarisaLovesUsAll
wrote:
When I make mixin injection in one class, I want auto-injection
in another class. How can I do this?
class Component:GameObject
{
//second injection must be here and must be automatic
};
class Sprite:Component
lve it. I think
this is about mixins/templates, isn't it?
When inherit from base class Component, I need to auto-create child own
static fields with child type.
It should look like this, after compilation:
class Component
{
//it doesn't matter to have any fields here
//but it&#x
(this)` in Manager:
mixin template Manager()
{
void someMethod(typeof(this) otherInstance) {}
}
Thanks, it works.
...I also have more questions %)
When I make mixin injection in one class, I want auto-injection
in another class. How can I do this?
class Component:GameObject
{
//s
On Thursday, 21 August 2014 at 12:58:13 UTC, MarisaLovesUsAll
wrote:
I found a rough solution. It's not ideal and I still want to
make autoinject, but it works.
mixin template Manager(T) {};
class Component {};
class Sprite:Component
{
mixin Manager!Sprite;
};
1) How to make mixin inject
ring getName(); };
class B { };
B foo = new B;
assert(foo.getName() == "B");
...
Hi! I'm stuck at one issue, and I don't know how to solve it. I
think this is about mixins/templates, isn't it?
When inherit from base class Component, I need to auto-create
child own stati
ates, isn't it?
When inherit from base class Component, I need to auto-create
child own static fields with child type.
It should look like this, after compilation:
class Component
{
//it doesn't matter to have any fields here
//but it's important to be able to create an in
On Wednesday, 20 August 2014 at 09:13:15 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
On Wed, 20 Aug 2014 01:38:52 +
uri via Digitalmars-d-learn
wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often
On Wed, 20 Aug 2014 01:38:52 +
uri via Digitalmars-d-learn wrote:
> Hi all,
>
> Bit new to D so this might be a very naive question...
>
> Can the compiler auto infer function attributes?
>
> I am often adding as many attributes as possible and use the
> compiler to s
On Wednesday, 20 August 2014 at 01:38:53 UTC, uri wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved
On Sunday, 3 August 2014 at 21:47:06 UTC, Artur Skawina via
Digitalmars-d-learn wrote:
void sort (R, T = ElementType!R, alias compare = less_than)(R
range, T item)
[should work iff the sort implementation only calls the
predicate]
artur
This works! Thanks!
On 08/03/14 23:19, Vlad Levenfeld via Digitalmars-d-learn wrote:
>
> I made less_than to serve as a default sorting predicate, so in a few places
> there is something like this:
>
> void sort (R, T = ElementType!R, alias compare = less_than!T)(R range, T item)
> {...}
void sort (R, T = Element
On Sunday, 3 August 2014 at 21:24:03 UTC, Vlad Levenfeld wrote:
certain data structures I use are not intended to be copied,
.
although these cases are probably better off being compared by
some kind of key rather than directly... so, auto ref isn't
necessary here, it was just some
On Sunday, 3 August 2014 at 20:10:39 UTC, Martijn Pot wrote:
What is the benefit of 'auto ref' over 'in' as you are changing
a nor b?
Because
less_than (T)(T a, T b)
(or in, or const T) will copy a and b on their way into the
function. Usually this is ok but certain d
places there is something like this:
void sort (R, T = ElementType!R, alias compare = less_than!T)(R
range, T item)
{...}
And since auto ref parameters need actual parameters to deduce
whether they should be ref or not, less_than!T isn't an
instantiated template - its still an alias, be
On Sunday, 3 August 2014 at 19:25:32 UTC, Vlad Levenfeld wrote:
This would make the function always take its argument by
reference. I'm trying to use the feature here:
http://dlang.org/template.html
from the section Function Templates with Auto Ref Parameters
I thought I finally
.065
$ cat less_than.d
bool less_than (T)(auto ref T a, auto ref T b)
{
return a < b;
}
void main()
{
int a = 1, b = 2;
assert(less_than(a, b));
assert(less_than(a, 2));
assert(less_than(1, b));
assert(less_than(1, 2));
}
$ dmd less_than.d &&
On Sunday, 3 August 2014 at 19:26:28 UTC, anonymous wrote:
Works for me with dmd versions back to 2.060. What compiler are
you using?
dmd 2.065
This would make the function always take its argument by
reference. I'm trying to use the feature here:
http://dlang.org/template.html
from the section Function Templates with Auto Ref Parameters
On Sunday, 3 August 2014 at 19:07:32 UTC, Vlad Levenfeld wrote:
bool less_than (T)(auto ref T a, auto ref T b)
{
return a < b;
}
Error: auto can only be used for template function parameters
Works for me with dmd versions back to 2.060. What compiler are
you using?
On Sunday, 3 August 2014 at 19:07:32 UTC, Vlad Levenfeld wrote:
This doesn't work:
bool less_than (T)(auto ref T a, auto ref T b)
{
return a < b;
}
Error: auto can only be used for template function parameters
What am I doing wrong? Is this not a template function?
I think
This doesn't work:
bool less_than (T)(auto ref T a, auto ref T b)
{
return a < b;
}
Error: auto can only be used for template function parameters
What am I doing wrong? Is this not a template function?
I commented in github.
Thx!
On Saturday, 7 June 2014 at 08:56:38 UTC, Nordlöw wrote:
My recent
https://github.com/D-Programming-Language/dmd/pull/3606
fails in all the Auto-Testers but I don't understand why.
Running make unittest locally in phobos using my locally built
branch of dmd passes all tests.
Please
On Saturday, 7 June 2014 at 09:19:55 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Also, you're probably going to need to use DMD= to set dmd to
the one that you
built in order to use the one that you built when building
druntime and Phobos
instead of the one you installed normally and is
On Sat, 07 Jun 2014 08:56:37 +
"Nordlöw" via Digitalmars-d-learn
wrote:
> My recent
>
> https://github.com/D-Programming-Language/dmd/pull/3606
>
> fails in all the Auto-Testers but I don't understand why.
>
> Running make unittest locally in phobos us
My recent
https://github.com/D-Programming-Language/dmd/pull/3606
fails in all the Auto-Testers but I don't understand why.
Running make unittest locally in phobos using my locally built
branch of dmd passes all tests.
Please help!
does not populate "test" with an empty double[int] AA. I
think there is conceptually an entry but that entry will be created
lazily when an element is added to it.
> auto innerAA = nestedAA["test"];
That line is not a reference to "test" but another nul
On 4/27/2014 9:32 PM, Ali Çehreli wrote:
fOn 04/27/2014 06:00 PM, David Held wrote:
> I would like to do something like this:
>
> Foo[Bar][Baz] nestedAA;
> auto innerAA = nestedAA[someBaz];
> innerAA[someBar] = someFoo;
> assert(someFoo in nestedAA[someBaz]);
in operat
fOn 04/27/2014 06:00 PM, David Held wrote:
> I would like to do something like this:
>
> Foo[Bar][Baz] nestedAA;
> auto innerAA = nestedAA[someBaz];
> innerAA[someBar] = someFoo;
> assert(someFoo in nestedAA[someBaz]);
in operator uses a key, not a value. This should work:
I would like to do something like this:
Foo[Bar][Baz] nestedAA;
auto innerAA = nestedAA[someBaz];
innerAA[someBar] = someFoo;
assert(someFoo in nestedAA[someBaz]);
Unfortunately, this does not do what I would like, because innerAA
appears to be a copy rather than a reference. Is there a nice
On Wednesday, 23 April 2014 at 23:05:39 UTC, Matthew Dudley wrote:
tuple in this case would be the member variable of type T (from
T...) So wouldn't elem be the actual object, and not the type?
The effective lowering I was hoping for would be something like
this
if (names[0] == "one")
re
On Wednesday, 23 April 2014 at 00:02:29 UTC, Jesse Phillips wrote:
On Tuesday, 22 April 2014 at 07:54:34 UTC, Matthew Dudley wrote:
Here's the gist of what I'm trying to do.
https://gist.github.com/pontifechs/11169069
I'm getting an error I don't understand:
tinker.d(42): Error: mismatched fu
On Tuesday, 22 April 2014 at 07:54:34 UTC, Matthew Dudley wrote:
Here's the gist of what I'm trying to do.
https://gist.github.com/pontifechs/11169069
I'm getting an error I don't understand:
tinker.d(42): Error: mismatched function return type inference
of tinker.B and tinker.A
tinker.d(55):
Matthew Dudley:
Also, as an aside, why can't tuples be indexed dynamically?
Most of my problems with this have been because you apparently
can't.
Think about how D tuples are implemented, they are essentially
structs. Every tuple element can have a different type and to be
represented in me
Here's the gist of what I'm trying to do.
https://gist.github.com/pontifechs/11169069
I'm getting an error I don't understand:
tinker.d(42): Error: mismatched function return type inference of
tinker.B and tinker.A
tinker.d(55): Error: template instance tinker.DynamicTuple!(A,
B).DynamicTuple
", i);
}
}
void main(string[] args)
{
int x = 2;
int y = 2;
alias myCopy = TCopy!(int, int);
myCopy.copy(x, y, 37);
writeln("x: ", x, " y: ", y);
}
My question is now why I have to declare and alias as in
alias myCopy = TCopy
On Fri, 04 Apr 2014 09:35:57 -0400, Bienlein wrote:
"auto" is used to declare an instance, or an object.
"alias" is used to declare a name.
What you are currently doing is saying "the function TCopy!(int, int)
can now be refered to as myCopy". You aren'
On Friday, 4 April 2014 at 13:23:48 UTC, Bienlein wrote:
template TCopy(T, V) {
[...]
}
On Friday, 4 April 2014 at 13:35:58 UTC, Bienlein wrote:
auto myCopy = new TCopy!(int, int);
alias myCopy = new TCopy!(int, int);
Neither nor compiles now. How can? Seems to me a template is
"auto" is used to declare an instance, or an object.
"alias" is used to declare a name.
What you are currently doing is saying "the function
TCopy!(int, int) can now be refered to as myCopy". You aren't
actually creating any data.
All right, thanks. Then
", i);
}
}
void main(string[] args)
{
int x = 2;
int y = 2;
alias myCopy = TCopy!(int, int);
myCopy.copy(x, y, 37);
writeln("x: ", x, " y: ", y);
}
My question is now why I have to declare and alias as in
alias myCopy = TCopy
int y = 2;
alias myCopy = TCopy!(int, int);
myCopy.copy(x, y, 37);
writeln("x: ", x, " y: ", y);
}
My question is now why I have to declare and alias as in
alias myCopy = TCopy!(int, int);
If I define auto instead of alias, it does no
stion are only ever assigned as slices of
underlying data, so they can be const(size_t)[][] from the
start.
So, thank you! :-)
I would still like to know if there's a way of enforcing
const-ness in an auto return type, though. You never know when
it could be useful.
This might be wort
ever assigned as slices of underlying data, so
they can be const(size_t)[][] from the start.
So, thank you! :-)
I would still like to know if there's a way of enforcing const-ness in an auto
return type, though. You never know when it could be useful.
On 25/11/13 12:00, bearophile wrote:
Is this acceptable?
struct Foo {
auto bar() {
const result = ...;
return result;
}
}
Could work, nice thought :-) I was hoping for something in the function
signature rather than internally, though.
Joseph Rushton Wakeling:
struct Foo
{
const(auto) bar()
{
// modifies internal data of Foo
// but returns a const type
}
}
Is this acceptable?
struct Foo {
auto bar() {
const result = ...;
return
On 25/11/13 10:13, Andrea Fontana wrote:
auto bar() { return cast(const int) 10; }
writeln(typeid(bar()));
Yup, I should have added that I would prefer to avoid a cast in the return
statement :-) Thanks anyway!
auto bar()
{
// I can't modify any of the
// internal data of Foo here
}
}
Suppose instead that I want a method that _may_ modify internal
data, but will return an entity that is itself const. Is there
any way to do this while having the return
Hello all,
If I mark a struct or class method as const, this is assumed to apply to the
entire method, i.e. that nothing in it will modify any internal data of the
struct/class.
struct Foo
{
const auto bar()
{
// I can't modify any o
and how virtual functions work. They just don't mix.
>
> Seems, the same problem doesn't allow auto attribute to virtual
> functions, because technically ,I think, possible get type from
> implemented functions, and if code trying to use return type not
> appropriate manner
In fact, since the template could be in a library, and code
could use that library well after the library has been
written...
As such, there is a fundamental conflict between how templates
work and how virtual functions work. They just don't mix.
Seems, the same problem doesn't
On Tuesday, 8 October 2013 at 13:40:47 UTC, Roman wrote:
```
interface I
{
//auto foo(int i); //forbidden
auto bar(T)(T i); //Error: function a.I.bar!(int).bar has no
function body with return type inference
}
Basically the error on the template answers your statement, bar
has no
On Tuesday, October 08, 2013 17:26:04 Roman wrote:
> Seems, I've tried to use virtual templates manner. But it doesn't
> realizes in D yet
Fundamentally, making templates virtual doesn't really work. If it's possible,
it would be quite difficult, and AFAIK, it's impossible. Templated functions
a
On Tuesday, 8 October 2013 at 13:40:47 UTC, Roman wrote:
```
interface I
{
//auto foo(int i); //forbidden
auto bar(T)(T i); //Error: function a.I.bar!(int).bar has no
function body with return type inference
}
class A:I
{
int foo(int i)
{
return i
```
interface I
{
//auto foo(int i); //forbidden
auto bar(T)(T i); //Error: function a.I.bar!(int).bar has no
function body with return type inference
}
class A:I
{
int foo(int i)
{
return i;
}
T bar(T)(T i
On Thursday, 26 September 2013 at 22:21:58 UTC, Matej Nanut wrote:
On Thursday, 26 September 2013 at 22:14:27 UTC, Joseph Rushton
Wakeling wrote:
It's what I was thinking of, but does that also work with a
dynamic array declaration?
int[] arr = new int[n];
Check out std.array.uninitialize
On Thursday, 26 September 2013 at 22:14:27 UTC, Joseph Rushton
Wakeling wrote:
It's what I was thinking of, but does that also work with a
dynamic array declaration?
int[] arr = new int[n];
Check out std.array.uninitializedArray.
Matej
On 26/09/13 23:23, H. S. Teoh wrote:
You mean:
int[10] arr = void;
It's what I was thinking of, but does that also work with a dynamic array
declaration?
int[] arr = new int[n];
On Thu, Sep 26, 2013 at 11:23:10PM +0200, Joseph Rushton Wakeling wrote:
> Hello all,
>
> Suppose I create a new dynamic array:
>
> auto arr = new int[10];
>
> If I recall right, the values inside arr will be auto-initialized to
> int.init (which is 0).
>
Hello all,
Suppose I create a new dynamic array:
auto arr = new int[10];
If I recall right, the values inside arr will be auto-initialized to int.init
(which is 0).
Again, if I recall right, there's a simple way to increase performance by not
auto-initializing the values, but I
;s just fundamentally not that much code, nor is it
actually difficult code.
Thanks very much for pointing me to that. I'm looking into auto-testing stuff
that would work with
a project hosted on Gitorious (GitHub is unsatisfactory for political reasons)
-- I'm working on the
assumpti
t
actually difficult code.
Thanks very much for pointing me to that. I'm looking into auto-testing stuff
that would work with a project hosted on Gitorious (GitHub is unsatisfactory for
political reasons) -- I'm working on the assumption that one of the standard
testing frameworks wi
On Wednesday, 25 September 2013 at 11:29:16 UTC, Jacob Carlborg
wrote:
On 2013-09-25 09:30, simendsjo wrote:
http://d.puremagic.com/test-results/
I know where the test results are. But, what I'm forgetting is
where the code is which implements these test results. I want
this page:
http://
On 2013-09-25 09:30, simendsjo wrote:
http://d.puremagic.com/test-results/
I know where the test results are. But, what I'm forgetting is where the
code is which implements these test results. I want this page:
http://d.puremagic.com/test-results/
To have a link to this:
https://github.co
On Wednesday, 25 September 2013 at 06:51:44 UTC, Jacob Carlborg
wrote:
On 2013-09-24 18:25, Brad Roberts wrote:
https://github.com/braddr/d-tester
Could you add a link to this on the test results page? I always
forget where this code is located.
http://d.puremagic.com/test-results/
On 2013-09-24 18:25, Brad Roberts wrote:
https://github.com/braddr/d-tester
Could you add a link to this on the test results page? I always forget
where this code is located.
--
/Jacob Carlborg
On 9/24/13 4:29 AM, Joseph Rushton Wakeling wrote:
On 24/09/13 13:01, Jacob Carlborg wrote:
It's custom. I would guess it either uses a git hook or it uses some API
provided by Github.
Ahh, OK. I was wondering if it used some standard tool to manage starting the
test jobs and
reporting back
On Tuesday, 24 September 2013 at 10:25:21 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
GitHub very nicely ensures that all pull requests to dmd,
druntime and phobos are sent to the auto-tester and that
success/failure reports are sent back.
But ... how is this done? Is the auto-tester
On 24/09/13 13:01, Jacob Carlborg wrote:
It's custom. I would guess it either uses a git hook or it uses some API
provided by Github.
Ahh, OK. I was wondering if it used some standard tool to manage starting the
test jobs and reporting back the tests -- something like Gerrit, Jenkins, etc.
I
On 2013-09-24 12:25, Joseph Rushton Wakeling wrote:
Hello all,
GitHub very nicely ensures that all pull requests to dmd, druntime and
phobos are sent to the auto-tester and that success/failure reports are
sent back.
But ... how is this done? Is the auto-tester entirely custom written or
does
Hello all,
GitHub very nicely ensures that all pull requests to dmd, druntime and phobos
are sent to the auto-tester and that success/failure reports are sent back.
But ... how is this done? Is the auto-tester entirely custom written or does it
use some standard tools? And how is it hooked
On Wednesday, 24 July 2013 at 11:26:32 UTC, Mike Parker wrote:
This is the exact behavior I would expect. I think of auto as
"this variable is going to be the same type as that variable."
Since in is const int, then j also is going to be const int. If
you want to copy n into
On Wednesday, 24 July 2013 at 11:26:32 UTC, Mike Parker wrote:
...
This is the exact behavior I would expect. I think of auto as
"this variable is going to be the same type as that variable."
Since in is const int, then j also is going to be const int. If
you want to copy n into
On Wednesday, July 24, 2013 10:07:54 Alex H wrote:
> This code:
>
> void test(const int n)
> {
> auto j = n;
> j++;
> }
>
> Gives this error:
> cannot modify const expression j
>
>
> Is this considered a feature or a bug? I would assume most people
&
On Wednesday, 24 July 2013 at 08:07:55 UTC, Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people
wouldn't want new variables inheriting
s end up quoting myself? ;)
Obviously, stripping is only fine for the copied object itself,
not for any internal refs.
const(int*) cpci;
auto mpci = cast()cpci; // const(int)*
Unqual!(typeof(cpci)) mpci2; // const(int)*
This works already; it's just that having to drop the quali
always fine (ie safe)
Nope. Stop. Wrong. Qualification is transitive in D, unlike in
C++. Even when copying, stripping qualification is not safe:
//
struct S
{
int* p;
}
void main()
{
immutable i = 1;
auto a = immutable(S)(&i);
auto b = cast(S)a; //Unsafe cast
like the one in OP, or unnecessary template
bloat. The IFTI special cases that are already there are just handling
one of the symptoms.
As you can always declare something as 'immutable' or 'const', instead
of 'auto', the default would have to be head-mutable [1]. Ie, t
On Wednesday, 24 July 2013 at 10:01:14 UTC, bearophile wrote:
dennis luehring:
and how would it look to preserve the const if auto would
auto-rip it of?
You could write:
immutable j = n;
For every default behavour you need a way to implement the
other nicely :-)
Currently for the
dennis luehring:
and how would it look to preserve the const if auto would
auto-rip it of?
You could write:
immutable j = n;
For every default behavour you need a way to implement the other
nicely :-)
Currently for the problem of the OP you can use this:
Unqual!(typeof(n)) j = n;
Bye
Am 24.07.2013 11:39, schrieb bearophile:
Alex H:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people wouldn't want new variables inheriting const.
It&#x
On Wednesday, 24 July 2013 at 08:07:55 UTC, Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people
wouldn't want new variables inheriting
Alex H:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people wouldn't want new variables inheriting const.
It's a bit annoying. I don't remember pe
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most people
wouldn't want new variables inheriting const.
On Thursday, July 04, 2013 21:54:22 Jeremy DeHaan wrote:
> I've seen a lot of code lately that uses the auto keyword when
> declaring variables, but for some reason I don't really care much
> for it.
>
> I'd like to make tutorials for a library I am working on, but I
On Thursday, 4 July 2013 at 20:00:18 UTC, Jeremy DeHaan wrote:
I've seen a lot of code lately that uses the auto keyword when
declaring variables, but for some reason I don't really care
much for it.
I'd like to make tutorials for a library I am working on, but I
want to use
I've seen a lot of code lately that uses the auto keyword when
declaring variables, but for some reason I don't really care much
for it.
I'd like to make tutorials for a library I am working on, but I
want to use "D style." Does such a style exist? Is auto generally
On 6/27/13, bearophile wrote:
>> On the other hand it could be useful in non-public and generic
>> code.
>
> Do you have a realistic use case for generic code?
No, I'm just speaking out loud about the possibility.
Andrej Mitrovic:
On the other hand it could be useful in non-public and generic
code.
Do you have a realistic use case for generic code?
Bye,
bearophile
On 6/27/13, bearophile wrote:
> So is it a good idea to allow "auto" in the function signature
> for the arguments that have a default value?
>
> void foo(in auto x = VeryLongNamedStruct(1)) {}
I've wanted this too once. Although there's a tradeoff here, now the
Sometimes I have code like this:
struct VeryLongNamedStruct {}
void foo(in VeryLongNamedStruct x = VeryLongNamedStruct(1)) {}
void main() {}
Or even:
void bar(in TupleFoo x = TupleFoo(TupleBar(2), TupleSpam(3))) {}
So is it a good idea to allow "auto" in the function signatur
l 'readLine' or 'readLineW', and then subsequently calling
'toUTF8' after that.
It just seems like something like this would be nice to have in phobos
if it's not already there.
The new stream replacement code is capable of doing this, all without much
eff
On 2013-04-09 18:25, Kai Meyer wrote:
I would like to know if there exists a 'stream' or 'file' class that is
able to take a text file with a correct BOM, and an 'ouput' utf
encoding. It want it to be capable of detecting the 'input' stream utf
encoding by using the BOM, and do the encoding for m
I would like to know if there exists a 'stream' or 'file' class
that is able to take a text file with a correct BOM, and an
'ouput' utf encoding. It want it to be capable of detecting the
'input' stream utf encoding by using the BOM, and do the encoding
for me on the way out in the specified 'o
On Friday, 29 March 2013 at 12:57:55 UTC, Martin Drasar wrote:
On 29.3.2013 11:59, Namespace wrote:
Ok I interpret this as a rejection of the idea.
This seems like a language design decision and as such would
get much
broader audience (and probably more responses) in digitalmars.D
than in
l
On 29.3.2013 11:59, Namespace wrote:
> Ok I interpret this as a rejection of the idea.
This seems like a language design decision and as such would get much
broader audience (and probably more responses) in digitalmars.D than in
learn forum. Threads in here can get overlooked easily.
Maybe you sh
Ok I interpret this as a rejection of the idea.
I'm surprised that this is ignored and no one seems to be
interested in a possible solution.
Is it me? Or are my efforts a complete mischief?
401 - 500 of 741 matches
Mail list logo
