On 05/29/2013 06:54 PM, Peter Williams wrote:
> On 30/05/13 10:49, Peter Williams wrote:
>> On 30/05/13 09:45, Ali Çehreli wrote:
>>>http://dlang.org/d-array-article.html
> Thinking about this some more, it seems I still need the const even with
> pass by value to reassure the caller that h
On 05/29/2013 10:54 PM, Maxim Fomin wrote:
> And this is a problem, because article about D slices encourages to call
> some raw memory (which almost never is directly manipulated and doesn't
> appear in source code) as a dynamic array, and dynamic array as a slice.
An array is simply consecutiv
On Thursday, 30 May 2013 at 05:54:57 UTC, Maxim Fomin wrote:
On Thursday, 30 May 2013 at 05:44:43 UTC, Diggory wrote:
On Thursday, 30 May 2013 at 05:41:06 UTC, Maxim Fomin wrote:
On Wednesday, 29 May 2013 at 23:45:04 UTC, Ali Çehreli wrote:
On 05/29/2013 03:59 PM, Peter Williams wrote:
> I've
On Thursday, 30 May 2013 at 01:56:03 UTC, Steven Schveighoffer
wrote:
On Wed, 29 May 2013 05:15:00 -0400, monarch_dodra
wrote:
On Tuesday, 28 May 2013 at 22:29:02 UTC, Steven Schveighoffer
wrote:
On Tue, 28 May 2013 17:11:06 -0400, monarch_dodra
wrote:
A proper implementation should be ab
Am 30.05.2013 07:41, schrieb Ali Çehreli:
On 05/29/2013 05:19 PM, MrzlganeE wrote:
> The := operator would allow to declare a variable, deduce
> its type, and define its value.
>
> void main() {
> x := 1;
> y := 2.0;
> z := x * y;
> y = 3.0;
> }
I like it.
Ali
I
On Thursday, 30 May 2013 at 05:44:43 UTC, Diggory wrote:
On Thursday, 30 May 2013 at 05:41:06 UTC, Maxim Fomin wrote:
On Wednesday, 29 May 2013 at 23:45:04 UTC, Ali Çehreli wrote:
On 05/29/2013 03:59 PM, Peter Williams wrote:
> I've been trying to find out how non ref array arguments are
passe
On Thursday, 30 May 2013 at 05:41:06 UTC, Maxim Fomin wrote:
On Wednesday, 29 May 2013 at 23:45:04 UTC, Ali Çehreli wrote:
On 05/29/2013 03:59 PM, Peter Williams wrote:
> I've been trying to find out how non ref array arguments are
passed to
> functions in D but can't find any documentation on
On Wednesday, 29 May 2013 at 23:45:04 UTC, Ali Çehreli wrote:
On 05/29/2013 03:59 PM, Peter Williams wrote:
> I've been trying to find out how non ref array arguments are
passed to
> functions in D but can't find any documentation on it.
The following concepts are relevant:
- Dynamic array: Ma
On 05/29/2013 05:19 PM, MrzlganeE wrote:
> The := operator would allow to declare a variable, deduce
> its type, and define its value.
>
> void main() {
> x := 1;
> y := 2.0;
> z := x * y;
> y = 3.0;
> }
I like it.
Ali
On Wednesday, 29 May 2013 at 22:44:17 UTC, Walter Bright wrote:
I still think it's a bad idea, but it's obvious people want it
in D, so it'll stay.
(Also note that I meant using ASCII, not necessarily english.)
Good, thanks, restrictions definetelly can and should be applied
per project, l
Ok, Diggory, thanks for your consideration. I want to keep the
code clean and direct, with reliable error messages, with
consistent output line numbers, with standard semantic highlight
support in D editors, etc. I do not want to use a level of
indirection or CTFE all of my code. I would rather
mixins make the code more ugly and the error messages' line numbers will
not be in sync with the code, IIRC.
I would like this syntax sugar too.
It's also used in GO, btw.
On Wed, May 29, 2013 at 7:52 PM, Diggory wrote:
> On Thursday, 30 May 2013 at 02:51:47 UTC, Diggory wrote:
>
>> On Thursday
On Thursday, 30 May 2013 at 02:51:47 UTC, Diggory wrote:
On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:
Diggory: That's very cool -- being able to do that in D.
Thanks for showing me :)
But it is not even a remotely practical solution.
The idea is to write less, and so the solu
On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:
Diggory: That's very cool -- being able to do that in D.
Thanks for showing me :)
But it is not even a remotely practical solution.
The idea is to write less, and so the solution you've given
is to write more mixins all over the p
On Wed, 29 May 2013 05:15:00 -0400, monarch_dodra
wrote:
On Tuesday, 28 May 2013 at 22:29:02 UTC, Steven Schveighoffer wrote:
On Tue, 28 May 2013 17:11:06 -0400, monarch_dodra
wrote:
A proper implementation should be able to track length anyway: provide
0(1) splice, and an "amortized"
On 30/05/13 10:49, Peter Williams wrote:
On 30/05/13 09:45, Ali Çehreli wrote:
Yes, simply pass-by-reference. Not expensive at all. There may be
surprises though; you may want to read this article:
http://dlang.org/d-array-article.html
Very informative article.
Thinking about this some m
On Wed, 29 May 2013 15:08:24 -0400, Jonathan M Davis
wrote:
Wrap the try-catch in a function.
I was about to suggest this. This is the correct solution.
-Steve
Diggory: That's very cool -- being able to do that in D. Thanks
for showing me :)
But it is not even a remotely practical solution.
The idea is to write less, and so the solution you've given
is to write more mixins all over the place. I said I don't even
want to write 'auto', I am surely
On Thursday, 30 May 2013 at 00:20:00 UTC, MrzlganeE wrote:
Hi,
Please consider a request for just one piece of syntax sugar in
D.
In places where I write a bunch of short mathy code, I do not
want to use 'auto'. The := operator would allow to declare a
variable, deduce its type, and define
So now that there's a pragma(mangle), we can start hacking this
up! I'm using Linux g++ 32 bit.
C++:
class Class {
public:
Class() {}// printf("constructed\n"); }
virtual void addNum(int a) { num += a; }
virtual void addNum2(int a) { num2 += a; }
void talk() { p
On Wednesday, 29 May 2013 at 21:45:38 UTC, Flamaros wrote:
Need some opinions for a GUI editor
You can combine both approaches: make the editor an external app
that would communicate with your running application (if it's
compiled in an editor-enabled mode).
On Wednesday, 29 May 2013 at 19
On Wednesday, 29 May 2013 at 16:24:00 UTC, Timon Gehr wrote:
On 05/29/2013 06:21 PM, Timon Gehr wrote:
On 05/29/2013 07:35 AM, Walter Bright wrote:
On 5/28/2013 9:55 PM, Diggory wrote:
As a last resort there should be a runtime check available
such as
assertNotNull(T) which does the conversio
On 30/05/13 09:45, Ali Çehreli wrote:
Yes, simply pass-by-reference. Not expensive at all. There may be
surprises though; you may want to read this article:
http://dlang.org/d-array-article.html
Very informative article.
Thanks
Peter
Hi,
Please consider a request for just one piece of syntax sugar in D.
In places where I write a bunch of short mathy code, I do not
want to use 'auto'. The := operator would allow to declare a
variable, deduce its type, and define its value.
void main() {
x := 1;
y := 2.0;
z :=
On 30/05/13 08:40, Entry wrote:
My personal opinion is that code should only be in English.
But why would you want to impose this restriction on others?
Peter
On 05/29/2013 04:45 PM, Ali Çehreli wrote:
> Yes, simply pass-by-reference. Not expensive at all.
Arggh! It should say "simply pass-by-value".
Ali
On 05/29/2013 03:59 PM, Peter Williams wrote:
> I've been trying to find out how non ref array arguments are passed to
> functions in D but can't find any documentation on it.
The following concepts are relevant:
- Dynamic array: Maintained by the D runtime
- Fixed-length array (aka static arr
Am Sun, 26 May 2013 21:25:36 +0200
schrieb "Joakim" :
> On Sunday, 26 May 2013 at 19:11:42 UTC, Mr. Anonymous wrote:
> > On Sunday, 26 May 2013 at 19:05:32 UTC, Joakim wrote:
> >> On Sunday, 26 May 2013 at 18:29:38 UTC, Andrei Alexandrescu
> >> wrote:
> >>> On 5/26/13 1:45 PM, Joakim wrote:
> >>>
On 24.5.2013. 1:58, bearophile wrote:
Peter Alexander:
What about code that relies on overflow? It's well-defined behaviour,
so it should be expected that people rely on it (I certainly do
sometimes)
Do you rely on signed or unsigned overflow?
My opinions on this topic have changed few times
Am Wed, 29 May 2013 15:44:17 -0700
schrieb Walter Bright :
> I still think it's a bad idea, but it's obvious people want it in D, so it'll
> stay.
>
> (Also note that I meant using ASCII, not necessarily english.)
Surprisingly ASCII also covers Cornish and Malay.
--
Marco
On 30/05/13 02:17, Ali Çehreli wrote:
On 05/28/2013 08:43 PM, Peter Williams wrote:
> One place I'm using it is for managing symbols (look ahead sets, etc) in
> a parser generator. The symbols' permanent home is in an associative
> array indexed by their name (which is also included in the s
On 29/05/13 19:40, monarch_dodra wrote:
The problem is that you are missing a FUNDAMENTAL difference between C++
and D. C++'s const merely says: "Though shalt not modify this value",
whereas D's means "This object's value WILL remain constant, until the
end of time, and under no circumstance can
On 5/29/2013 2:42 AM, Jakob Ovrum wrote:
On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
I've recently come to the opinion that that's a bad idea, and D should not
support it.
Honestly, removing support for non-ASCII characters from identifiers is the
worst idea you've had in a wh
On 5/29/2013 3:26 AM, qznc wrote:
Once I heared an argument from developers working for banks. They coded
business-specific stuff in Java. Business-specific meant financial concepts with
german names (e.g. Vermögen,Bürgschaft), which sometimes include äöüß. Some of
those concept had no good trans
My personal opinion is that code should only be in English.
On Wed, 29 May 2013 08:43:44 -0400, Jakob Ovrum
wrote:
On Wednesday, 29 May 2013 at 12:40:39 UTC, Dicebot wrote:
Why something like this is not usable?
---
int tmp;
try
{
tmp = ...;
}
catch(..)
{
}
const(int) i = tmp;
---
Not really pretty but nothi
On Wednesday, 29 May 2013 at 19:38:57 UTC, Martin Nowak wrote:
On 05/28/2013 11:25 PM, Flamaros wrote:
Hi,
I and a friend are developing a GUI library, and now our
script engine
is ready to start a prototype (but far to be finished).
What do you use for rendering?
We use OpenGL 2.1, we ta
On Wednesday, 29 May 2013 at 19:35:31 UTC, Jacob Carlborg wrote:
On 2013-05-29 12:22, Flamaros wrote:
You think it's easier to do or to use?
I would think it's easier to develop such editor. Probably just
as easy to use as a built in editor.
We can't do serialization because our GUI files
On 5/29/2013 4:00 AM, Russel Winder wrote:
I'm not sure I would call it component – didn't components die in the
1980 when no-one could agree what a component was?
Everybody has a different definition of "component". What I'm talking about here
are interchangeable blocks of functionality which
On 05/29/2013 06:48 AM, Russel Winder wrote:
Is there a planned replacement?
We want to have a range based replacement, but it's nowhere near in sight.
Am 29.05.2013 06:48, schrieb Russel Winder:
On Tue, 2013-05-28 at 19:51 +0200, Martin Nowak wrote:
[…]
This is only available for std.stream
http://dlang.org/phobos/std_stream.html#.MemoryStream.
This package has a big red "deprecated" notice, so I didn't look at it.
Is this an indication that
On 2013-05-29 12:22, Flamaros wrote:
You think it's easier to do or to use?
I would think it's easier to develop such editor. Probably just as easy
to use as a built in editor.
We can't do serialization because our GUI files are lua scripts.
I assume you will have some kind of objects fl
On 05/28/2013 11:25 PM, Flamaros wrote:
Hi,
I and a friend are developing a GUI library, and now our script engine
is ready to start a prototype (but far to be finished).
What do you use for rendering?
On Wednesday, May 29, 2013 15:08:24 Jonathan M Davis wrote:
> Wrap the try-catch in a function.
>
> int foo()
> {
> int initI()
> {
> try
> return createTheVar();
> catch(Exception e)
> return int.init;
> }
Ouch, my e-mail client ate the indentation. That should be
int initI()
{
On Wednesday, May 29, 2013 14:36:18 Jakob Ovrum wrote:
> Consider the following example:
>
> http://dpaste.dzfl.pl/a0595ddf
>
> // Can throw, and we want to catch
> int createTheVar();
>
> // Can also throw, but we don't want to catch it here
> int transform(int a);
>
> int foo()
> {
> cons
On 05/29/2013 09:09 AM, Johannes Pfau wrote:
We only have to do the library versioning right.
The phobos make file currently builds libphobos2.so.0.63.0 and uses
libphobos2.so.0.63 as the soname. So an app linked with the shared
phobos will be using libphobos2.so.0.63, the .63 comes from the
On Wednesday, 29 May 2013 at 17:58:19 UTC, Jesse Phillips wrote:
On Wednesday, 29 May 2013 at 12:51:24 UTC, Jakob Ovrum wrote:
On Wednesday, 29 May 2013 at 12:48:15 UTC, Flamaros wrote:
Maybe you'll do a pull request to migrate to luaD when we'll
open the repository.
I will, I imagine it woul
Am Wed, 29 May 2013 19:05:09 +0200
schrieb Martin Nowak :
> On 05/29/2013 01:08 PM, Maxim Fomin wrote:
> > Actually it fails because _aaDelX calls gc, and gc is not reenterable.
> > It has nothing to do with static or thread locals.
> Right, you currently can't perform GC operations in a finalizer
Another example just came up:
http://dlang.org/phobos/std_process.html#.executeShell
you can redirect to Files, but not easily to strings or pipes or
something you can handle in memory. Blargh.
On Wednesday, 29 May 2013 at 12:51:24 UTC, Jakob Ovrum wrote:
On Wednesday, 29 May 2013 at 12:48:15 UTC, Flamaros wrote:
Maybe you'll do a pull request to migrate to luaD when we'll
open the repository.
I will, I imagine it would be a pleasure. Deleting all that
tedious, bug-prone stack-based
On Wednesday, 29 May 2013 at 16:46:09 UTC, Jeremy DeHaan wrote:
On Wednesday, 29 May 2013 at 11:08:55 UTC, Maxim Fomin wrote:
On Wednesday, 29 May 2013 at 10:33:32 UTC, deadalnix wrote:
On Wednesday, 29 May 2013 at 07:32:42 UTC, Jeremy DeHaan
wrote:
Thoughts?
static variables are thread loca
On Wednesday, 29 May 2013 at 17:28:52 UTC, Martin Nowak wrote:
On 05/28/2013 11:25 PM, Flamaros wrote:
2) Integrated editor (launch with the user application in a
second Window)
a) Good :
- Preview is the final result with real data
- All application components accessible to the editor
On 05/28/2013 11:25 PM, Flamaros wrote:
2) Integrated editor (launch with the user application in a second Window)
a) Good :
- Preview is the final result with real data
- All application components accessible to the editor without
complex plugin system (in this way all editors compon
On 2013-05-29 16:02:58 +, "Daniel Murphy" said:
Introduce *C (syntax not important) to give you the raw class type,
much like the raw function type. You can then apply const directly to
this type, and an appropriate suffix gets you back to the reference.
Are you sure you're not starting
29-May-2013 21:01, Timon Gehr пишет:
On 05/29/2013 03:15 PM, Dmitry Olshansky wrote:
[snip]
In fact most of Phobos they already use in place lambdas to get mock
l-values of type T.
This begs the question of usefulness of T.init and should ALL types have
it.
T.init also has some other subtl
On 5/29/13 11:44 AM, Kenji Hara wrote:
Andrei, if the variable type has some indirections, it would be
correctly rejected.
@safe void foo()
{
int* x = void; // error
}
Error: variable test.foo.x void initializers for pointers not allowed in
safe functions
So I'm not sure bug 10201 is corr
On 05/29/2013 01:08 PM, Maxim Fomin wrote:
Actually it fails because _aaDelX calls gc, and gc is not reenterable.
It has nothing to do with static or thread locals.
Right, you currently can't perform GC operations in a finalizer.
Removing an element of a hashtable may trigger an internal
reorga
On 05/29/2013 03:15 PM, Dmitry Olshansky wrote:
29-May-2013 16:18, Dicebot пишет:
On Wednesday, 29 May 2013 at 09:28:38 UTC, Walter Bright wrote:
The whole point of a notnull is to disallow default initialization.
Beg my pardon if that was already discussed by how does that interfere
with var
On Wednesday, 29 May 2013 at 11:08:55 UTC, Maxim Fomin wrote:
On Wednesday, 29 May 2013 at 10:33:32 UTC, deadalnix wrote:
On Wednesday, 29 May 2013 at 07:32:42 UTC, Jeremy DeHaan wrote:
Thoughts?
static variables are thread local. Are you sure the destructor
run in the same thread as the con
On 05/29/2013 06:25 AM, Jakob Ovrum wrote:
> I was unable to leverage std.exception.
I have looked only your short example. std.exception.ifThrown may work:
import std.typecons;
import std.exception;
alias ToThrow = Flag!"ToThrow";
// Can throw, and we want to catch
int createTheVar(ToThrow t
On Wednesday, 29 May 2013 at 15:02:53 UTC, Regan Heath wrote:
Which is what exactly? That 2 features not-null and @disable
this() are the same thing? They're not, one is a subset of the
other. That they require the same compiler functionality, we
all agree, but that's not really important or
On 05/29/2013 07:35 AM, Walter Bright wrote:
On 5/28/2013 9:55 PM, Diggory wrote:
As a last resort there should be a runtime check available such as
assertNotNull(T) which does the conversion.
The idea is to put the check on assignments to NotNull, not on usage of it.
This is like allowing a
On 05/29/2013 06:21 PM, Timon Gehr wrote:
On 05/29/2013 07:35 AM, Walter Bright wrote:
On 5/28/2013 9:55 PM, Diggory wrote:
As a last resort there should be a runtime check available such as
assertNotNull(T) which does the conversion.
The idea is to put the check on assignments to NotNull, no
On 05/28/2013 08:43 PM, Peter Williams wrote:
> One place I'm using it is for managing symbols (look ahead sets, etc) in
> a parser generator. The symbols' permanent home is in an associative
> array indexed by their name (which is also included in the symbol
> object) but they may belong to man
On Wednesday, 29 May 2013 at 15:11:53 UTC, Andrei Alexandrescu
wrote:
How does C# solve it?
I can't find the blog posts, but I think it's basically just a
very good implementation of definite assignment analysis[1],
without any inter-procedural analysis. So, nothing spectacular
(though I thi
On 05/28/2013 11:13 PM, Jonathan M Davis wrote:
> On Tuesday, May 28, 2013 22:58:39 Ali Çehreli wrote:
> To make matters worse, what happens when you have a const object
which has a
> reference as a member variable? e.g.
>
> class C
> {
> class D d;
> }
>
> const C c;
Thanks for doing th
"Michel Fortin" wrote in message
news:ko3ri4$kkb$1...@digitalmars.com...
>>
>> Michel Fortin has created a pull request to make
>>
>> const(T)ref
>>
>> work, and only apply the const to the data. It's certainly doable. But
>> the syntax, as you can see, is ugly.
>
> Well, that pull request was
On Wednesday, 29 May 2013 at 15:14:54 UTC, Kenji Hara wrote:
With 2.063, this code would work.
struct S { int* ptr; } // has mutable indirection
void main()
{
immutable S si = function () pure
{
S sm;
sm.ptr = new int;
*sm.ptr = 10;
return sm; // constr
On Wednesday, 29 May 2013 at 15:11:53 UTC, Andrei Alexandrescu
wrote:
How does C# solve it?
I'm failing to find this really good blog post by a C# designer I
read a while ago that explains how it works. I'll keep looking;
my memory is fuzzy on the details and I wouldn't be able to
explain it
On Wednesday, 29 May 2013 at 15:44:59 UTC, Kenji Hara wrote:
Andrei, if the variable type has some indirections, it would be
correctly
rejected.
@safe void foo()
{
int* x = void; // error
}
Error: variable test.foo.x void initializers for pointers not
allowed in
safe functions
So I'm no
Andrei, if the variable type has some indirections, it would be correctly
rejected.
@safe void foo()
{
int* x = void; // error
}
Error: variable test.foo.x void initializers for pointers not allowed in
safe functions
So I'm not sure bug 10201 is correct or not...
Kenji Hara
2013/5/30 Dice
On 05/29/2013 05:07 AM, Jesse Phillips wrote:
Outsider summary:
* Implementing @disable provides the groundwork for a working
non-nullable type
* Non-nullable types cannot make a working @disable
Adding non-nullable to a library
* Implement NotNullable!T
Adding non-nullable to the language
*
On Wednesday, 29 May 2013 at 15:11:53 UTC, Andrei Alexandrescu
wrote:
I must have missed part of this - how would the desired setup
work?
Andrei
Maybe something like the following would work. collectException's
return value and out parameter have been swapped for
demonstration - an out par
On Wednesday, 29 May 2013 at 15:19:42 UTC, Andrei Alexandrescu
wrote:
YES. Oh boy how the heck did we miss that.
Andrei
Makes sense :)
http://d.puremagic.com/issues/show_bug.cgi?id=10201
On 5/29/13 11:15 AM, Dicebot wrote:
On Wednesday, 29 May 2013 at 15:10:42 UTC, Andrei Alexandrescu wrote:
"= void" is a low-level unsafe feature which is not influenced by
disabling the default constructor.
Andrei
It is allowed in @safe. Should I file a bug report?
YES. Oh boy how the heck
On Wednesday, 29 May 2013 at 15:10:42 UTC, Andrei Alexandrescu
wrote:
"= void" is a low-level unsafe feature which is not influenced
by disabling the default constructor.
Andrei
It is allowed in @safe. Should I file a bug report?
On 5/29/13 9:21 AM, Dicebot wrote:
On Wednesday, 29 May 2013 at 13:15:48 UTC, Dmitry Olshansky wrote:
...
Actually as I can see, at least part of Phobos uses void instead of
T.init, but, anyway, won't this break for types with proper @disable this?
--
template i
On 5/29/13 9:25 AM, Jakob Ovrum wrote:
On Wednesday, 29 May 2013 at 13:19:34 UTC, deadalnix wrote:
I guess the first assignment of a variable should be considered as a
declaration unless it has been read in between. This is the same
problem as immutable constructor, and also relate to extra copi
With 2.063, this code would work.
struct S { int* ptr; } // has mutable indirection
void main()
{
immutable S si = function () pure
{
S sm;
sm.ptr = new int;
*sm.ptr = 10;
return sm; // construct and return mutable object
}();
static assert(is(typ
On 5/29/13 5:20 AM, deadalnix wrote:
On Wednesday, 29 May 2013 at 07:50:39 UTC, Kenji Hara wrote:
Currently I recognize that it is necessary to fix compiler bugs around
@disable this(); at least.
@deadalnix, it seems to me that you argue that @disable this(); is
insufficient or useless to imple
On Wed, 29 May 2013 15:56:28 +0100, deadalnix wrote:
On Wednesday, 29 May 2013 at 14:47:31 UTC, Regan Heath wrote:
This behavior isn't useful. You'll find no argument except
historical reason (which is a very valid argument
BTW) to keep that. Everything else is backward rationalization.
If
On Wednesday, 29 May 2013 at 14:47:31 UTC, Regan Heath wrote:
This behavior isn't useful. You'll find no argument except
historical reason (which is a very valid argument
BTW) to keep that. Everything else is backward
rationalization.
If @disable is insufficient for a NotNull!(T) which does wh
2013/5/29 Adam D. Ruppe
> On Wednesday, 29 May 2013 at 04:15:52 UTC, Walter Bright wrote:
>
>> It's not in Phobos yet:
>>
>
> I did a pull request a while ago that stalled for some reason I don't
> remember now, but the struct I did needed to be a little more complex than
> yours to pass all the
On Wed, 29 May 2013 15:09:11 +0100, deadalnix wrote:
On Wednesday, 29 May 2013 at 13:36:16 UTC, Regan Heath wrote:
Most people agree that you'll find 2 useful behavior : non nullable
and nullable with obligation of handling
the null case. The default behavior right now provide none of thoses.
On 5/29/13 1:56 AM, Diggory wrote:
On Wednesday, 29 May 2013 at 05:35:14 UTC, Walter Bright wrote:
On 5/28/2013 9:55 PM, Diggory wrote:
As a last resort there should be a runtime check available such as
assertNotNull(T) which does the conversion.
The idea is to put the check on assignments to
On Wednesday, 29 May 2013 at 13:52:31 UTC, Paulo Pinto wrote:
Do blend works with C++?
Yes, in Windows 8 Apps when doing XAML with C++/CX.
After 16 years, Microsoft finally catches up with Borland's C++
Builder.
I don't know how it "run on top" but on the documentation page
tell that it
On Wednesday, 29 May 2013 at 13:36:16 UTC, Regan Heath wrote:
Which default behaviour? D's references/pointers? Or the
proposed NotNull!(T) library solution?
The default behavior. The one you get our of the box. So not
NonNullable.
This behavior isn't useful. You'll find no argument exce
On Wednesday, 29 May 2013 at 12:41:44 UTC, Flamaros wrote:
On Wednesday, 29 May 2013 at 11:36:54 UTC, Paulo Pinto wrote:
On Wednesday, 29 May 2013 at 09:40:33 UTC, Flamaros wrote:
On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote:
On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wr
On Wednesday, 29 May 2013 at 13:44:15 UTC, Jakob Ovrum wrote:
On Wednesday, 29 May 2013 at 13:35:18 UTC, Maxim Fomin wrote:
It is not casting away const and it has nothing to do with
immutable, also this does not suffer from data was actually
immutable problem.
The data is not initially const
On Wednesday, 29 May 2013 at 13:35:18 UTC, Maxim Fomin wrote:
It is not casting away const and it has nothing to do with
immutable, also this does not suffer from data was actually
immutable problem.
The data is not initially constructed by the local function, it's
clearly coming from somewhe
On Wed, 29 May 2013 14:15:07 +0100, deadalnix wrote:
On Wednesday, 29 May 2013 at 12:19:54 UTC, Regan Heath wrote:
I started discussing this because people where claiming that non null
makes the compiler more complex to implement, which is completely
false.
That's not the argument being m
On Wednesday, 29 May 2013 at 13:30:09 UTC, Jakob Ovrum wrote:
However, since const/mutable aliasing is allowed, you can do:
union U (T)
{
const T ct;
T mt;
}
because const doesn't mean that object would never change, you
can mutate it through alias. From the opposite view, there is
also n
On Wednesday, 29 May 2013 at 13:21:21 UTC, Maxim Fomin wrote:
Fundamental issue here is that
const T t;
is almost useless, it is essentially immutable since you cannot
change it and you cannot alias it. As such, it probably should
be changed to a mutable object or an immutable one.
It's ge
On Wednesday, 29 May 2013 at 12:50:36 UTC, Dicebot wrote:
I have been thinking about this long time ago. Clearly, slice
semantics will change in GC-less environment and will require
more restrictive operation set. No automatic slice
concatenation at the very least.
Right. Without implementing
On Wednesday, 29 May 2013 at 13:19:34 UTC, deadalnix wrote:
I guess the first assignment of a variable should be considered
as a declaration unless it has been read in between. This is
the same problem as immutable constructor, and also relate to
extra copies elimination.
Yeah, and languages
On Wednesday, 29 May 2013 at 13:15:48 UTC, Dmitry Olshansky wrote:
...
Actually as I can see, at least part of Phobos uses void instead
of T.init, but, anyway, won't this break for types with proper
@disable this?
--
template isInputRange(R)
{
enum bool is
On Wednesday, 29 May 2013 at 12:36:19 UTC, Jakob Ovrum wrote:
I need to be able to catch an exception that may have been
thrown during the initialization of `i`, but still have `i` be
const. I can't omit the variable because I *don't* want to
accidentally catch anything that transform() may hav
On Wednesday, 29 May 2013 at 12:43:46 UTC, Jakob Ovrum wrote:
On Wednesday, 29 May 2013 at 12:40:39 UTC, Dicebot wrote:
Why something like this is not usable?
---
int tmp;
try
{
tmp = ...;
}
catch(..)
{
}
const(int) i = tmp;
---
Not really pretty but not
29-May-2013 16:18, Dicebot пишет:
On Wednesday, 29 May 2013 at 09:28:38 UTC, Walter Bright wrote:
The whole point of a notnull is to disallow default initialization.
Beg my pardon if that was already discussed by how does that interfere
with various T.init use cases in current code? Most impor
On Wednesday, 29 May 2013 at 12:19:54 UTC, Regan Heath wrote:
I started discussing this because people where claiming that
non null makes the compiler more complex to implement, which
is completely false.
That's not the argument being made by Simen. The argument is
that @disable this() is a
1 - 100 of 163 matches
Mail list logo
