On 2012-07-10 22:53, Jonathan M Davis wrote:
Well, giving an error, continuing to parse, and giving a partial result can be
useful (and you give a prime example of that), but fixing the problem (e.g by
inserting the semicolon) and not considering it to be an error would be a
_huge_ mistake
On Wednesday, July 11, 2012 08:41:53 Jacob Carlborg wrote:
On 2012-07-10 22:53, Jonathan M Davis wrote:
Well, giving an error, continuing to parse, and giving a partial result
can be useful (and you give a prime example of that), but fixing the
problem (e.g by inserting the semicolon) and
On Tuesday, 10 July 2012 at 21:51:44 UTC, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 23:35:02 monarch_dodra wrote:
1. In general, I wouldn't recommend not caring whether a
variable is a
container or a range. It matters a great deal to the semantics
of what you're
doing.
2. At this
Am 10.07.2012 07:13, schrieb Jonathan M Davis:
On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
Am 10.07.2012 00:53, schrieb Jonathan M Davis:
On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
Clear uses the TypeInfo. The proposed functions should not be library
functions but
On Wednesday, July 11, 2012 09:28:15 Benjamin Thaut wrote:
Am 10.07.2012 07:13, schrieb Jonathan M Davis:
On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
Am 10.07.2012 00:53, schrieb Jonathan M Davis:
On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
Clear uses the
In the past few months working on my little hobby project I came across
many bugs, and almost all of them are connected to structs in one or the
other way. So I made a list of all the bugs that affected me and are
connected to structs:
Destruction of uninitialized temporary struct with assert
On 10/07/12 19:13, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why on earth is druntime acting as if it does?
Y'know, this brings up
+1
I trying to build DMD + druntime + phobos. I builded DMD using
Visual Studio solution file. But when i try to build druntime it
says corruptet druntime.obj. How to build it on windows? Maybe
it is possible to build it using mingw?
Am 11.07.2012 09:33, schrieb Jonathan M Davis:
On Wednesday, July 11, 2012 09:28:15 Benjamin Thaut wrote:
Am 10.07.2012 07:13, schrieb Jonathan M Davis:
On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
Am 10.07.2012 00:53, schrieb Jonathan M Davis:
On Monday, July 09, 2012 22:41:57
Timon Gehr , dans le message (digitalmars.D:171814), a écrit :
On 07/11/2012 01:16 AM, deadalnix wrote:
On 09/07/2012 10:14, Christophe Travert wrote:
deadalnix , dans le message (digitalmars.D:171330), a écrit :
D isn't 100% CFG. But it is close.
What makes D fail to be a CFG?
On Wednesday, 11 July 2012 at 07:52:40 UTC, Benjamin Thaut wrote:
Structs are a really important language feature that also often
is supposed to be used as a replacement for deperecated
features (scope, typedef, ...)
Scope is deprecated? I didn't see that in the Changelog...
On 2012-07-11 02:03, Walter Bright wrote:
So do I. But all language design involves tradeoffs. I believe the
advantages of const toHash etc. outweigh the disadvantage of less
straightforward memoization.
Can't there be non-const versions of these methods as well?
--
/Jacob Carlborg
On Wednesday, July 11, 2012 10:40:29 monarch_dodra wrote:
On Wednesday, 11 July 2012 at 07:52:40 UTC, Benjamin Thaut wrote:
Structs are a really important language feature that also often
is supposed to be used as a replacement for deperecated
features (scope, typedef, ...)
Scope is
So, i have builded druntime with dmc, but why it isn't builds
with cl?
Am 11.07.2012 11:11, schrieb crashtua:
So, i have builded druntime with dmc, but why it isn't builds with cl?
Certain parts of druntime are written in C and must be build with dmc.
Also I don't know if building with Visual Studio is supported yet as the
Visual Studio compiler can not do 84
On 2012-07-11 02:20, Timon Gehr wrote:
I for one would be satisfied if inheriting from object became optional:
// object.di
class RawObject /+ this is the root of the class hierarchy +/{ }
class SynchronizableObject : RawObject { void* monitor; }
class Object : SynchronizableObject {
const {
On 2012-07-11 08:52, Jonathan M Davis wrote:
??? I guess that I wasn't clear. I mean that with HTML, it ignores errors. The
browser doesn't spit out errors. It just guesses at what you really meant and
displays that. It fixes the error for you, which is a horrible design IMHO.
Obviously, we're
If you create a class/struct that can give you a (forward) range
via opSlice(), and that range gives you access to opApply,
then you get two different behaviors:
MyClass arr = ...;
foreach(a; arr)
...
foreach(a; arr[])
...
In the first case, foreach will call opSlice(), and
Giving Array an opApply operator fixes both problems:
1) It allows modifying the elements when accessed with ref.
2) It allows writing ++a even though ++front isn't supported.
I implemented this and made a pull request:
https://github.com/D-Programming-Language/phobos/pull/683
I implemented
if needed, the operator !! (double exclamation mark) could be
defined.
it is just an idea, i do not have any specific use in mind.
i encountered the operator in RT operating systems book:
c!!e sends the message e along channel c
c?x assigns to variable x the value from c
maybe this could be
On 11-07-2012 13:18, akaz wrote:
if needed, the operator !! (double exclamation mark) could be defined.
it is just an idea, i do not have any specific use in mind.
i encountered the operator in RT operating systems book:
c!!e sends the message e along channel c
c?x assigns to variable x the
On Wednesday, 11 July 2012 at 11:18:21 UTC, akaz wrote:
if needed, the operator !! (double exclamation mark) could be
defined.
Problem is that operator!! is already used asa twin
operator!. This is shorthand for is valid as bool:
When a type can be casted to bool, it is quicker to write
Andrei Alexandrescu , dans le message (digitalmars.D:171828), a écrit :
On 7/10/12 5:19 PM, H. S. Teoh wrote:
There is value in immutable objects that has been well discussed, which
is incompatible with logical constness. We can change the language such
as: a given type X has the option to
On 11/07/12 13:47, monarch_dodra wrote:
On Wednesday, 11 July 2012 at 11:18:21 UTC, akaz wrote:
if needed, the operator !! (double exclamation mark) could be defined.
Problem is that operator!! is already used asa twin operator!. This
is shorthand for is valid as bool:
I wouldn't be
On 7/10/12 10:22 PM, Walter Bright wrote:
On 7/10/2012 6:53 PM, Andrei Alexandrescu wrote:
On 7/10/12 9:14 PM, Walter Bright wrote:
Anyhow, the point of @trusted is to notify the maintainer that here be
dragons.
I think that's not representing @trusted quite accurately. There's no
dragon
On 7/10/12 10:33 PM, Jonathan M Davis wrote:
Yeah. It seems to me that a reasonable approach would be to give Object two
versions of opEquals, opCmp, toString, and toHash - a const and non-const
version of each. The non-const version then calls the const version. So, the
normal thing to do is
On 7/11/12 12:59 AM, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 04:59:28AM +0200, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But
conservative type systems
When i try to build latest druntime i get such errors:
src\core\simd.d(53): Error: template instance
core.simd.Vector!(double[4u]) erro
r instantiating
src\core\simd.d(35): Error: base type of __vector must be a 16
byte static array
, not float[8u]
src\core\simd.d(54): Error: template
On 7/11/12 3:58 AM, Don Clugston wrote:
Something I wonder about, though, is how many different use cases are we
dealing with?
Suppose we had a caching solution (you could think of it as @cached, but
it could be done in a library). The user would need to provide a const,
pure function which
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
cached value when building the object.
Doing the calculation at that point avoid synchronization cost involved
On 7/11/12 8:55 AM, Andrei Alexandrescu wrote:
The cost of getting to the stash is
proportional to the number of objects within the thread that make use of
that stash.
Oops, that would be with linear search :o).
Andrei
On Wednesday, 11 July 2012 at 12:55:39 UTC, Andrei Alexandrescu
wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
As for me, lazy computation (with caching) would likely be the
last feature I really miss in D.
On 07/11/2012 01:33 PM, Alex Rønne Petersen wrote:
On 11-07-2012 13:18, akaz wrote:
if needed, the operator !! (double exclamation mark) could be defined.
it is just an idea, i do not have any specific use in mind.
i encountered the operator in RT operating systems book:
c!!e sends the
On 11-07-2012 15:42, Timon Gehr wrote:
On 07/11/2012 01:33 PM, Alex Rønne Petersen wrote:
On 11-07-2012 13:18, akaz wrote:
if needed, the operator !! (double exclamation mark) could be defined.
it is just an idea, i do not have any specific use in mind.
i encountered the operator in RT
On 07/11/2012 10:23 AM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:171814), a écrit :
On 07/11/2012 01:16 AM, deadalnix wrote:
On 09/07/2012 10:14, Christophe Travert wrote:
deadalnix , dans le message (digitalmars.D:171330), a écrit :
D isn't 100% CFG. But it is
On 11/07/2012 03:30, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 01:19:16 UTC, Andrei Alexandrescu wrote:
On 7/10/12 6:05 PM, Walter Bright wrote:
A straightforward workaround is to use PIMPL to encapsulate the logical
const stuff, and then cast the reference to const to use inside the
On 10/07/2012 22:11, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 12:00:59 H. S. Teoh wrote:
I think hidden somewhere in this is an unconscious conflation of
physical const with logical const.
I completely disagree at least as far as classes go. opEquals, opCmp,
toString, and toHash must
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
cached value when building the object.
And sometimes it is not known in
On 11/07/2012 13:18, akaz wrote:
if needed, the operator !! (double exclamation mark) could be defined.
it is just an idea, i do not have any specific use in mind.
So why do you do a proposal if this is not needed ?
On 11/07/2012 02:20, Timon Gehr wrote:
On 07/11/2012 01:57 AM, Walter Bright wrote:
On 7/10/2012 4:16 PM, Timon Gehr wrote:
Const is stronger than what is required to bridge the gap between
mutable and immutable. It guarantees that a reference cannot be used to
mutate the receiver regardless
monarch_dodra , dans le message (digitalmars.D:171868), a écrit :
I'm wondering if this is the correct behavior? In particular,
since foreach guarantees a call to opSlice(), so writing arr[]
*should* be redundant, yet the final behavior is different.
That said, the issue *could* be fixed
On 11/07/2012 16:16, deadalnix wrote:
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
cached value when building the object.
On Wednesday, 11 July 2012 at 14:08:55 UTC, deadalnix wrote:
On 11/07/2012 13:18, akaz wrote:
So why do you do a proposal if this is not needed ?
I did not ask for it, I only reminded that it is possible to
define it if needed. It's merely a suggestion. I was reading a
book and told myself:
On Jul 11, 2012, at 12:58 AM, Don Clugston d...@nospam.com wrote:
On 10/07/12 19:13, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why
On 07/11/2012 02:55 PM, Andrei Alexandrescu wrote:
...
If this is a useful artifact, Walter had an idea a while ago that we can
have the compiler help by using the per-object monitor pointer instead
of the static hashtable. Right now the pointer points to a monitor
object, but it could point to
On 07/11/2012 02:39 PM, Andrei Alexandrescu wrote:
On 7/10/12 10:59 PM, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But conservative
type systems are not
On 07/11/2012 02:40 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:59 AM, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 04:59:28AM +0200, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as
Hi,
On 11-07-2012 01:54, Antti-Ville Tuunainen wrote:
I'm working on the precise gc patches. I now have a bunch of templates
and all the other infrastructure, but what's holding me back is that I
don't quite understand the .di files.
DI files are exactly what header files are in C(++) (there
On 7/11/12 10:33 AM, Timon Gehr wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
Andrei
Well, it is inefficient.
The idea here is to assess functionality provided in order to decide
whether to go down this route or not.
Andrei
On Wednesday, 11 July 2012 at 14:10:35 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think foreach should never call opSlice. That's not in the
online
documentation
(http://dlang.org/statement.html#ForeachStatement), unless
I missed something. If you want to use foreach on a
On Tuesday, 10 July 2012 at 23:54:49 UTC, Antti-Ville Tuunainen
wrote:
[…] However, for any kind of efficiency, the templates also
need to be able to directly call functions and/or access the
state from src/gc/gcx.d. I cannot just import it, because it
won't be available during (user code)
On Wednesday, 11 July 2012 at 14:42:43 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 10:33 AM, Timon Gehr wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
Andrei
Well, it is inefficient.
The idea here is to assess functionality provided in order to
On Wednesday, 11 July 2012 at 14:42:43 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 10:33 AM, Timon Gehr wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
Andrei
Well, it is inefficient.
The idea here is to assess functionality provided in order to
On Tuesday, 10 July 2012 at 23:54:49 UTC, Antti-Ville Tuunainen
wrote:
[…] However, for any kind of efficiency, the templates also
need to be able to directly call functions and/or access the
state from src/gc/gcx.d. I cannot just import it, because it
won't be available during (user code)
On Wednesday, 11 July 2012 at 13:55:30 UTC, deadalnix wrote:
The cached value can in fact rely outside the object.
For the umpteenth time, I am not talking about caching.
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu
wrote:
I was a long-time proponent of this. It's less exciting than it
may seem actually.
(a) Classes that work with const just fine incur one extra
virtual call. I think this can be avoided by having the
compiler plant the same
On 07/11/2012 04:16 PM, deadalnix wrote:
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate
On 07/11/2012 04:16 PM, deadalnix wrote:
On 11/07/2012 16:16, deadalnix wrote:
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed
I think the online documentation
(http://dlang.org/statement.html#ForeachStatement) is not sufficient.
foreach (e; aggr) { ...body...}
Current dmd translates above foreach statement like follows.
1. If aggr has opApply or opApplyReverse, it's used.
2. If aggr has empty/front/popFront:
2a. If
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei Alexandrescu
wrote:
I gave evidence on a large, high quality C++ codebase that the
use of mutable (which is the solution of choice for
memoization, caching, and lazy computation) is extremely scarce.
What evidence do you have for your
On Mon, 09 Jul 2012 07:44:24 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 07/09/2012 08:37 AM, Adam Wilson wrote:
Object is now const-correct throughout D. This has been a dream for many
of you. Today it is a reality.
PITA. Forced const can severely harm a code base that wants to be
On 7/11/12 11:03 AM, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that work with const just fine incur one extra virtual
call. I think this can be avoided
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei Alexandrescu wrote:
I gave evidence on a large, high quality C++ codebase that the use of
mutable (which is the solution of choice for memoization, caching, and
lazy computation) is extremely scarce.
monarch_dodra , dans le message (digitalmars.D:171902), a écrit :
I just re-read the docs you linked to, and if that was my only
source, I'd reach the same conclusion as you.
I think the reference spec for D should be the community driven and
widely available website, not a commercial book.
On 07/11/2012 05:27 PM, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that work with const just fine incur one extra
On Wednesday, 11 July 2012 at 15:28:41 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei
Alexandrescu wrote:
I gave evidence on a large, high quality C++ codebase that
the use of
mutable (which is the solution of
On 7/11/12 11:50 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 15:28:41 UTC, Andrei Alexandrescu wrote:
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei Alexandrescu wrote:
I gave evidence on a large, high quality C++ codebase that the use of
On 11/07/2012 17:49, Timon Gehr wrote:
On 07/11/2012 05:27 PM, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that
About 2 million in C++.
source:
http://www.ohloh.net/p/qt/analyses/latest/languages_summary
On Wed, Jul 11, 2012 at 10:28 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
How many lines total?
Andrei
On Wednesday, 11 July 2012 at 15:57:51 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 11:50 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 15:28:41 UTC, Andrei
Alexandrescu wrote:
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei
Alexandrescu wrote:
On 07/11/2012 05:27 PM, Andrei Alexandrescu wrote:
We can't really model every possible design.
If it cannot be modelled, it is not a possible design.
On 7/11/12 11:33 AM, Caligo wrote:
About 2 million in C++.
source:
http://www.ohloh.net/p/qt/analyses/latest/languages_summary
I agree that 1500 occurrences of mutable in 2 million lines of C++ is
quite large.
Andrei
On 7/11/12 12:12 PM, Timon Gehr wrote:
On 07/11/2012 05:27 PM, Andrei Alexandrescu wrote:
We can't really model every possible design.
If it cannot be modelled, it is not a possible design.
There is if it can be modeled in a less constrained language.
Andrei
On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
[...]
This solution is not for allowing people to use lazy computation in
their const overrides, it's for allowing people to still use
opEquals, toString etc. even if their implementations cannot
On 7/11/12 12:14 PM, Max Samukha wrote:
Sorry, I misunderstood the question. As I said earlier, the relative
number of lines with 'mutable' is mostly irrelevant. What is more
relevant is the ratio of types defining at least one mutable member to
the total number of types.
I understand that. I
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I can't
cache anything. And this isn't just about
Short keywords are only important with barebones editors like
a default vi.
Nobody would use this for real development.
I started I long discussion on Reddit, because I complained
that the goal of 5 letter keywords is primitive, and brings
back memories of the time the compilers were memory
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I can't
cache anything. And this isn't just about
On Wednesday, 11 July 2012 at 16:45:17 UTC, David Piepgrass wrote:
Anyway I think short vs long is much ado about nothing. No one
complains that we have to type int instead of integer,
after all. Most languages have only a few keywords, which
people quickly learn. As long as all the standard
On Sunday, 8 July 2012 at 19:28:11 UTC, Walter Bright wrote:
On 7/8/2012 6:49 AM, bearophile wrote:
I think in Go the function stack is segmented and growable as
in Go. This saves
RAM if you need a small stack, and avoids stack overflows
where lot of stack is
needed.
The trouble with
On 11/07/2012 18:30, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
[...]
This solution is not for allowing people to use lazy computation in
their const overrides, it's for allowing people to still use
opEquals, toString
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as fn, but
while many languages use fun, requiring function for all functions
is almost unheard of (at least I haven't heard of it), why? It's too
damn long! We write functions constantly,
On Wednesday, 11 July 2012 at 17:09:27 UTC, Timon Gehr wrote:
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as
fn, but
while many languages use fun, requiring function for all
functions
is almost unheard of (at least I haven't
On 11-07-2012 19:09, Timon Gehr wrote:
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as fn, but
while many languages use fun, requiring function for all functions
is almost unheard of (at least I haven't heard of it), why? It's too
On Wednesday, 11 July 2012 at 15:59:21 UTC, deadalnix wrote:
If it cannot and should not be const, it isn't a comparison or
an equality test, it is another operation altogether that is
performed.
That's bullshit. You've seen the example I raised. How can you
tell me it's not an equality
On Wednesday, 11 July 2012 at 15:27:55 UTC, Andrei Alexandrescu
wrote:
I think I'll find it rather difficult to get behind modeling
arbitrary escapes from immutability. If you want classes, you
buy into a certain contract with inherent rights and
constraints (starting with using references).
All problems was in path to dmd and dmc. Absolute path to them
solved all problems. Thanks for reply.
On 7/11/12 1:04 PM, Timon Gehr wrote:
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results.
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take something
obvious like a class object representing a dataset in a database. How is
an immutable instance of such a class useful?
This is a good point. It seems we're subjecting all classes to
On 11/07/2012 19:46, Andrei Alexandrescu wrote:
On 7/11/12 1:04 PM, Timon Gehr wrote:
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for
On 11/07/2012 19:32, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 15:59:21 UTC, deadalnix wrote:
If it cannot and should not be const, it isn't a comparison or an
equality test, it is another operation altogether that is performed.
That's bullshit. You've seen the example I raised. How
On Sunday, 8 July 2012 at 21:04:05 UTC, jerro wrote:
As someone that values readable code, I don't understand this
desire to turn every programming language into APL.
I would expect the abbreviations that rust uses to be perfectly
readable once you know the langauge.
I like a lot ML
On 7/11/12 1:49 PM, deadalnix wrote:
I think they should. Comparing the same object 2 time should
definitively have the same result back, otherwise things will go
horribly wrong soon enough.
Yah, but e.g. a comparison may log something.
Andrei
On Wednesday, 11 July 2012 at 17:47:41 UTC, deadalnix wrote:
To be fair, I know nothing about LUA.
It's Lua.
But you are talking here about discussing with another
language, so, by definition, don't have the same semantic than
D.
This is irrelevant. The Lua API is a C library like any
On Wed, Jul 11, 2012 at 01:50:23PM -0400, Andrei Alexandrescu wrote:
On 7/11/12 1:49 PM, deadalnix wrote:
I think they should. Comparing the same object 2 time should
definitively have the same result back, otherwise things will go
horribly wrong soon enough.
Yah, but e.g. a comparison may
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take something
obvious like a class object representing a dataset in a database. How is
an immutable instance of such a class useful?
This is a good
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 mailing list and felt unable to
participate because they kept using terminology
1 - 100 of 202 matches
Mail list logo
