"David Piepgrass" wrote in message
news:jdyhfsxgucfglqgaj...@forum.dlang.org...
Rust has type classes from Haskell (with some simplifications for higher
kinds), uniqueness typing, and typestates.
As nice as kinds, typestates, typeclasses and several pointer types may be,
I was in the Rust mai
"David Piepgrass" , dans le message (digitalmars.D:172007), a écrit :
> @mutating class B : A
> {
> private int _x2;
> public @property override x() { return _x2++; }
> }
A fun() pure;
You can't cast the result of fun to immutable, because it may be a B
instance.
"David Piepgrass" , dans le message (digitalmars.D:172009), a écrit :
>> Now, I recognize and respect the benefits of transitive
>> immutability:
>> 1. safe multithreading
>> 2. allowing compiler optimizations that are not possible in C++
>> 3. ability to store compile-time immutable literals in R
"Jonathan M Davis" , dans le message (digitalmars.D:172005), a écrit :
> On Wednesday, July 11, 2012 13:46:17 Andrei Alexandrescu wrote:
>> I don't think they should be pure. Do you have reasons to think otherwise?
>
> As I understand it, Walter's current plan is to require that opEquals, opCmp,
I think spawnlinked will do the job for me, thank you.
Timon Gehr , dans le message (digitalmars.D:172014), a écrit :
> Thank you for taking the time.
>
> Removing the default methods completely is actually a lot better than
> making inheriting from Object optional or tweaking const beyond
> recognition and/or usefulness.
> I was afraid to suggest t
On Thursday, July 12, 2012 07:31:02 Christophe Travert wrote:
> "Jonathan M Davis" , dans le message (digitalmars.D:172005), a écrit :
> > On Wednesday, July 11, 2012 13:46:17 Andrei Alexandrescu wrote:
> >> I don't think they should be pure. Do you have reasons to think
> >> otherwise?
> >
> > As
"Mehrdad" , dans le message (digitalmars.D:172012), a écrit :
> On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu
> wrote:
>> Required reading prior to this: http://goo.gl/eXpuX
>
> Referenced post (for context):
>>> The problem is not only in the constness of the argument, but
>>>
On Thursday, July 12, 2012 00:15:48 Andrei Alexandrescu wrote:
> What say you?
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently working idioms to
no longer work:
1. Anything which wants to be able to operate on Objects gene
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking inside
the box but we should question the very existence of the box. Once the
necessity of opCmp, opEqual
On Monday, 2 July 2012 at 11:44:27 UTC, Timon Gehr wrote:
Improving pseudo function call syntax:
http://forum.dlang.org/thread/uufohvapbyceuaylo...@forum.dlang.org
This is not a feature request. It is a feature sketch at best.
Sketchy or not, I posted that one as an enhancement request there
I posted this as an enhancement request over there:
http://d.puremagic.com/issues/show_bug.cgi?id=8381
On Thursday, 12 July 2012 at 08:40:25 UTC, Jonathan M Davis wrote:
it does appear to solve the const issues that we've been having
quite nicely
How would we expect people to deal with these const issues when
the issues come up in their own libraries?
Or do we not care?
On Thursday, July 12, 2012 11:07:42 Mehrdad wrote:
> On Thursday, 12 July 2012 at 08:40:25 UTC, Jonathan M Davis wrote:
> > it does appear to solve the const issues that we've been having
> > quite nicely
>
> How would we expect people to deal with these const issues when
> the issues come up in t
Am Wed, 11 Jul 2012 22:58:07 +0200
schrieb "bearophile" :
> > => a = 5s;
>
> I read that as "5 seconds" :-(
Me too, but then again "5l" could be read as 5 liters. I guess that is why the
move is towards uppercase suffixes. 5S and 5L are not likely misread.
> I don't think your examples justify
On 7/12/2012 12:59 AM, Jonathan M Davis wrote:
So, I think that it's probably a solid way to go, and it does appear to solve
the const issues that we've been having quite nicely, but it also appears to
break a number of things which have worked for some time, and we're going to
have to figure out
On Thursday, July 12, 2012 02:43:09 Walter Bright wrote:
> On 7/12/2012 12:59 AM, Jonathan M Davis wrote:
> > So, I think that it's probably a solid way to go, and it does appear to
> > solve the const issues that we've been having quite nicely, but it also
> > appears to break a number of things w
On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all
thinking inside
the box but we should question th
Have you considered adding operator overloading using UFCS while
you're at it?
Am Thu, 12 Jul 2012 11:42:13 +0200
schrieb Marco Leise :
> Am Wed, 11 Jul 2012 22:58:07 +0200
> schrieb "bearophile" :
>
> > > => a = 5s;
> >
> > I read that as "5 seconds" :-(
>
> Me too, but then again "5l" could be read as 5 liters. I guess that is why
> the move is towards uppercase suffix
On 07/12/2012 12:05 PM, Thiez wrote:
Have you considered adding operator overloading using UFCS while you're
at it?
There is already an open issue about that iirc.
On 12/07/12 12:00, Paulo Pinto wrote:
On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking in
Andrei Alexandrescu:
What say you?
It's an interesting proposal, and I like it in general.
In D the C++-improved template system and the Java-copied OOP are
partially a duplication, they sometimes offer two different ways
to do similar things. I think this proposal reduces this
duplication
On Wednesday, 11 July 2012 at 11:18:21 UTC, akaz wrote:
if needed, the operator !! (double exclamation mark) could be
defined.
...
Or the operator?? could be borrowed from c#
auto a = foo ?? new Foo();
is short for:
auto a = foo is null ? new Foo() : foo;
/Jonas
Andrei Alexandrescu:
The issue is template code bloat. My impression from being in
touch with the C++ community for a long time is that virtually
nobody even talks about code bloat anymore. For whatever
combination of industry and market forces, it's just not an
issue anymore.
There is no p
"bearophile" wrote in message
news:xrbtkoercscroxgto...@forum.dlang.org...
Andrei Alexandrescu:
What say you?
It's an interesting proposal, and I like it in general.
In D the C++-improved template system and the Java-copied OOP are partially
a duplication, they sometimes offer two different
Another weapon to attack the problem is introducing in the DMD
back-end an optimization (already present in LLVM, but I think
not used on default), merging of functions with the same body
(leaving just a jump as the body of the removed function, to
keep their function pointers distinct).
Why
Tobias Pankrath:
Why not drop that requirement? What is the use case of
different function pointers for different but equivalent
functions? Does anyone depend on this?
It's a requirement that comes from C specs, and I don't know why
C was designed that way, as usual I am not expert enough. I
"bearophile" wrote in message
news:thmrfdsenkmtasilh...@forum.dlang.org...
>
> Another weapon to attack the problem is introducing in the DMD back-end an
> optimization (already present in LLVM, but I think not used on default),
> merging of functions with the same body (leaving just a jump as
On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu
wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
[...]
What say you?
Andrei
I agree, they are not needed.
This situation is similar to C#, but there the problem doesn't
seem to be so severe
"Jonas Drewsen" , dans le message (digitalmars.D:172039), a écrit :
> On Wednesday, 11 July 2012 at 11:18:21 UTC, akaz wrote:
>> if needed, the operator !! (double exclamation mark) could be
>> defined.
>>
>> ...
>
> Or the operator?? could be borrowed from c#
>
> auto a = foo ?? new Foo();
>
>
On 07/11/2012 03:50 PM, Walter Bright wrote:
On 7/11/2012 11:54 AM, David Piepgrass wrote:
That reminds me, I was so happy the first two times I got an undefined
symbol
error in D. The compiler said: "Did you mean ''?" LOL,
don't tell me how it works... it's magic, right? I love a good error
mes
Christophe Travert, dans le message (digitalmars.D:172047), a écrit :
> "Jonas Drewsen" , dans le message (digitalmars.D:172039), a écrit :
>> On Wednesday, 11 July 2012 at 11:18:21 UTC, akaz wrote:
>>> if needed, the operator !! (double exclamation mark) could be
>>> defined.
>>>
>>> ...
>>
>> O
Daniel Murphy:
This should be in the linker, not the backend.
What's important is that all D compilers implement this
optimization (or something better, if compatible, like merging
pieces of partially equal functions).
Bye,
bearophile
On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko wrote:
Jon Skeet wrote on this long ago:
http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx
The fact that every object has a monitor associated with it was a
mistake in Java, and was un
On 2012-07-12 09:59, Jonathan M Davis wrote:
For the most part, I think that operating on Objects like that is horrible,
and we certainly don't encourage it, but it's been possible for ages, so I'm
willing to bet that there's plenty of code which does it. For instance, what's
Tango do? As I unde
On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko wrote:
Jon Skeet wrote on this long ago:
http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx
The fact that every object has
On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote:
Have you considered adding operator overloading using UFCS
while you're at it?
I assumed it's already possible to add operators non-intrusively,
because operators are just syntactic sugar for method calls:
++var; // actual
On 2012-07-12 13:41, bearophile wrote:
There is no proof that template bloat won't be a problem in D (I
remember the first version of the D Objective-C bridge failing because
of code bloat, the second version seems to require changes in the D
language).
Yeah, that was insane. 60 MB for a hello
On 2012-07-12 13:57, bearophile wrote:
It's a requirement that comes from C specs, and I don't know why C was
designed that way, as usual I am not expert enough. I prefer to not
change the semantics of D over C unless there is an important reason,
especially when I don't know/understand the rati
On 2012-07-12 13:35, Jonas Drewsen wrote:
Or the operator?? could be borrowed from c#
auto a = foo ?? new Foo();
is short for:
auto a = foo is null ? new Foo() : foo;
/Jonas
I really like that operator. The existential operator, also known as the
Elvis operator :) . It's available in man
Jacob Carlborg:
Yeah, that was insane. 60 MB for a hello world application is
not pretty.
I'd like to know how much MB are saved using the @templated()
pervasively in that first implementation... :-)
The second version is not a bridge, it changes the language to
be ABI
compatible with Obje
On Wed, 11 Jul 2012 17:20:08 -0400, deadalnix wrote:
Const is a bridge between mutable and immutable world. The guarantee
proposed with const is that it never mutate an immutable data. This is
slightly different than how const is implemented actually, but still
ensure that no immutable dat
On Thursday, 12 July 2012 at 12:43:24 UTC, Tommi wrote:
On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote:
Have you considered adding operator overloading using UFCS
while you're at it?
I assumed it's already possible to add operators
non-intrusively, because operators are just syntactic
On Thu, 12 Jul 2012 03:18:51 -0400, Christophe Travert
wrote:
"David Piepgrass" , dans le message (digitalmars.D:172007), a écrit :
@mutating class B : A
{
private int _x2;
public @property override x() { return _x2++; }
}
A fun() pure;
You can't cast the result of fun to immutabl
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently working idioms to
no longer work:
1. Anything which wants to be able to operate on Objects generically (e.g.
have a container full
On 2012-07-12 11:41:46 +, "bearophile" said:
Andrei Alexandrescu:
The issue is template code bloat. My impression from being in touch
with the C++ community for a long time is that virtually nobody even
talks about code bloat anymore. For whatever combination of industry
and market forc
Am Thu, 12 Jul 2012 08:22:59 -0400
schrieb Jeff Nowakowski :
> On 07/11/2012 03:50 PM, Walter Bright wrote:
> > On 7/11/2012 11:54 AM, David Piepgrass wrote:
> >> That reminds me, I was so happy the first two times I got an undefined
> >> symbol
> >> error in D. The compiler said: "Did you mean '
On Thursday, 12 July 2012 at 13:20:47 UTC, Andrei Alexandrescu
wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently
working idioms to
no longer work:
1. Anything which wants
On 2012-07-12 13:01:42 +, "bearophile" said:
Jacob Carlborg:
Yeah, that was insane. 60 MB for a hello world application is not pretty.
I'd like to know how much MB are saved using the @templated()
pervasively in that first implementation... :-)
There's no use for @templated() in the b
On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
wrote:
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking inside
the box but we should question the very existence of the box. Once the
necessity of opCmp, opEquals, toHash, toString is being
On Thursday, 12 July 2012 at 12:43:01 UTC, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko
wrote:
Jon Skeet wrote on this long ago:
http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-s
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently working
idioms to
no longer work:
1. Anything which wants t
On Thursday, 12 July 2012 at 12:43:01 UTC, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
The fact that every object has a monitor associated with it
was a
mistake in Java, and was unfortunately copied in .NET. This
promotes the bad practice of locking on
On Thursday, 12 July 2012 at 13:39:54 UTC, Steven Schveighoffer
wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
wrote:
If we define alternative free generic functions in object.d
for the four culprit methods (and have the compiler, druntime,
and stdlib use them instead of the me
On Thursday, 12 July 2012 at 13:41:52 UTC, Roman D. Boiko wrote:
...
ups. I meant +1.
On Thursday, 12 July 2012 at 13:35:54 UTC, Roman D. Boiko wrote:
OK, I found one myself from this post:
http://michelf.com/weblog/2012/mutex-synchonization-in-d/
Beat me :)
On Thursday, 12 July 2012 at 12:51:38 UTC, Jacob Carlborg wrote:
On 2012-07-12 13:35, Jonas Drewsen wrote:
Or the operator?? could be borrowed from c#
auto a = foo ?? new Foo();
is short for:
auto a = foo is null ? new Foo() : foo;
/Jonas
I really like that operator. The existential oper
On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently working
idioms t
On Thursday, 12 July 2012 at 13:19:00 UTC, Thiez wrote:
It's already quite obvious that the compiler does not obey its
own rewrite rules (see
http://dlang.org/operatoroverloading.html#compare) Consider
opCmp:
a < b
is rewritten to
a.opCmp(b) < 0
or
b.opCmp(a) > 0
Let's assume the first rule
Andrei Alexandrescu:
Too complicated. I think we can afford one comparison.
An annotation for old style classes?
Bye,
bearophile
On Thursday, 12 July 2012 at 13:49:29 UTC, Andrei Alexandrescu
wrote:
Too complicated. I think we can afford one comparison.
One comparison for each of these basic usages. Would branch
prediction work fine in each use case?
Anyway I vote for removing those methods from the root class.
Jacob Carlborg , dans le message (digitalmars.D:172056), a écrit :
> On 2012-07-12 13:35, Jonas Drewsen wrote:
>
>> Or the operator?? could be borrowed from c#
>>
>> auto a = foo ?? new Foo();
>>
>> is short for:
>>
>> auto a = foo is null ? new Foo() : foo;
>>
>> /Jonas
>>
>
> I really like that
"Thiez" , dans le message (digitalmars.D:172060), a écrit :
>>> Have you considered adding operator overloading using UFCS
>>> while you're at it?
>>
>> I assumed it's already possible to add operators
>> non-intrusively, because operators are just syntactic sugar for
>> method calls:
>>
>> ++va
Is this really need?
The four const operators in Object should not block the user-defined
mutable operators.
// My purpose for 2.060 release
class C {
override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
bool opEquals(Object o) { ... } // add overload for
On Thursday, 12 July 2012 at 11:03:37 UTC, Don Clugston wrote:
On 12/07/12 12:00, Paulo Pinto wrote:
On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I
On 12/07/2012 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking inside
the box but we should question the very existence of the box. Once the
necessity of opCmp, opEqu
On 12/07/2012 11:51, Jonathan M Davis wrote:
On Thursday, July 12, 2012 02:43:09 Walter Bright wrote:
On 7/12/2012 12:59 AM, Jonathan M Davis wrote:
So, I think that it's probably a solid way to go, and it does appear to
solve the const issues that we've been having quite nicely, but it also
ap
On Thu, Jul 12, 2012 at 12:59:16AM -0700, Jonathan M Davis wrote:
[...]
> 1. Anything which wants to be able to operate on Objects generically
> (e.g. have a container full of Objects) is going to have problems,
> since comparison and hashing won't work anymore. For the standard
> stuff, at minimu
On 12/07/2012 15:49, Andrei Alexandrescu wrote:
On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potenti
On 12/07/2012 13:21, bearophile wrote:
Andrei Alexandrescu:
What say you?
It's an interesting proposal, and I like it in general.
In D the C++-improved template system and the Java-copied OOP are
partially a duplication, they sometimes offer two different ways to do
similar things. I think t
kenji hara:
Is this really need?
...But, I would never opposed to advancing toward the better
language design.
I am not expert on English language, but you are one of my
programming heroes, so please let me try to improve a little
those parts of your post :-)
| Is this really necessary?
On 7/12/12 10:40 AM, deadalnix wrote:
And one branching. In itself it isn't high cost, but can become a
problem in a tight loop, say a sort function for instance.
Cost should be assessed in comparison to the baseline work that is being
performed. At any rate, the branch predictor should take c
On 12/07/2012 13:41, bearophile wrote:
Another weapon to attack the problem is introducing in the DMD back-end
an optimization (already present in LLVM, but I think not used on
default), merging of functions with the same body (leaving just a jump
as the body of the removed function, to keep thei
On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
> On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
> wrote:
[...]
> >3. opCmp, opEquals, and toHash are all needed primarily for one
> >thing: built-in hashes. (There's also use of them in the moribund
> >.sort method.) T
On 12/07/2012 16:28, kenji hara wrote:
Is this really need?
The four const operators in Object should not block the user-defined
mutable operators.
// My purpose for 2.060 release
class C {
override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
bool opEq
On Wednesday, 11 July 2012 at 20:24:42 UTC, Jonathan M Davis
wrote:
The problem is that it's essentially spread out across 3
places: the online
spec, TDPL, and the compiler.
...
- Jonathan M Davis
The problem is not only the documentation, it's getting
authoritative answers. I see some stra
On Thursday, 12 July 2012 at 14:31:34 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
This behavior for opEquals is debatable, but make sense.
I don't think it's debatable at all. You must be able to figure
out how a class is going to behave just by looking at its
definition.
On 7/12/12 10:28 AM, kenji hara wrote:
Is this really need?
The four const operators in Object should not block the user-defined
mutable operators.
// My purpose for 2.060 release
class C {
override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
bool opEq
On 12/07/2012 13:50, Tobias Pankrath wrote:
Another weapon to attack the problem is introducing in the DMD
back-end an optimization (already present in LLVM, but I think not
used on default), merging of functions with the same body (leaving
just a jump as the body of the removed function, to keep
deadalnix:
That is IMO the way to go instead of cluttering the language.
I think several solutions applied at the same time are needed if
you desire to reduce bloat effectively.
Bye,
bearophile
On 12/07/2012 16:55, bearophile wrote:
deadalnix:
That is IMO the way to go instead of cluttering the language.
I think several solutions applied at the same time are needed if you
desire to reduce bloat effectively.
Bye,
bearophile
The @templated is redundant with that backend capability
On 12/07/2012 15:20, Michel Fortin wrote:
On 2012-07-12 11:41:46 +, "bearophile" said:
Andrei Alexandrescu:
The issue is template code bloat. My impression from being in touch
with the C++ community for a long time is that virtually nobody even
talks about code bloat anymore. For whateve
deadalnix:
The @templated is redundant with that backend capability of LDC.
The semantics is not the same. This code doesn't compile, the
compiler enforces you are not using T in code that is annotated
to be a template of just V:
struct Foo(T, V) {
@templated(V) T bar() { return T.init;
On Thursday, 12 July 2012 at 09:32:00 UTC, Jonathan M Davis wrote:
The issue that we're trying to solve here is making
opEquals,opCmp, toHash, and toString work both for const and
non-const objects. That's it. We're not talking about revamping
const. It doesn't need it.
Depends on what you me
On Thu, 12 Jul 2012 09:30:35 -0400, Michel Fortin
wrote:
D/Objective-C (the compiler addition) is much more than that. It's
support and cohabitation of a second object ABI, it's support for
Objective-C exceptions mixed with D exceptions, support for Objective-C
string and selector litera
On 7/12/12 11:50 AM, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb isn't a
big deal for any modern computer, not even for most cell phones now.
On Thu, 12 Jul 2012 10:56:13 -0400, H. S. Teoh
wrote:
On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
wrote:
[...]
>3. opCmp, opEquals, and toHash are all needed primarily for one
>thing: built-in hashes. (There
On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb
isn't a big deal for any modern computer, not even for most
cell phones now.
L1 cache size is.
On Thu, 12 Jul 2012 11:47:10 -0400, Mehrdad wrote:
But if you're saying this problem is somehow 'special' in some way, then
would you please mention how?
Because you have no choice what your base class is -- Object. And if
Object uses const, so must you.
-Steve
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix wrote:
Both desirable things, but I don't think those would have much impact on
the D/Objective-C bridge.
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb isn't a big
deal for
On Thu, 12 Jul 2012 09:49:29 -0400, Andrei Alexandrescu
wrote:
On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However
On Thu, Jul 12, 2012 at 11:51:15AM -0400, Steven Schveighoffer wrote:
> On Thu, 12 Jul 2012 10:56:13 -0400, H. S. Teoh
> wrote:
>
> >On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
[...]
> >>Yes. Where's that new AA struct, Mr. Teoh? :)
> >[...]
> >
> >The code is still her
"Jonas Drewsen" wrote in message
news:zwtvliaunccmtwmab...@forum.dlang.org...
>
> auto a = foo ?? new Foo();
>
> is short for:
>
> auto a = foo is null ? new Foo() : foo;
>
> /Jonas
>
Yeah, I've been planning to try and get this into D one day. Probably
something like:
(a ?: b) -> (auto __tmp
On 12/07/2012 17:51, Andrei Alexandrescu wrote:
On 7/12/12 11:50 AM, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb isn't a
big deal for any mode
On 12/07/2012 18:09, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix wrote:
Both desirable things, but I don't think those would have much impact on
the D/Objective-C bridge.
I think this is not a problem as big as it is stated.
Most of that code will be execut
Am Thu, 12 Jul 2012 12:08:07 +0200
schrieb Marco Leise :
> Am Thu, 12 Jul 2012 11:42:13 +0200
> schrieb Marco Leise :
>
> > Am Wed, 11 Jul 2012 22:58:07 +0200
> > schrieb "bearophile" :
> >
> > > > => a = 5s;
> > >
> > > I read that as "5 seconds" :-(
> >
> > Me too, but then again "5l" could
On 12-07-2012 18:33, deadalnix wrote:
On 12/07/2012 18:09, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix
wrote:
Both desirable things, but I don't think those would have much
impact on
the D/Objective-C bridge.
I think this is not a problem as big as it is st
One thing PHP has been good at is evolving, and introducing change in
the language (some can argument that the language is so fucked up that
this is unavoidable, so I do it now and we can discuss interesting topic).
I discussed that system with Rasmus Ledorf at afup 2012 and it something
that
food for thought:
http://semver.org/
1 - 100 of 192 matches
Mail list logo
