On 2012-11-29 22:45, Andrei Alexandrescu wrote:
# Build script in Ruby
target :foo do
end
You should picture that this doesn't make any sense to someone not
knowing Ruby (beyond a possible misspelling of "voodoo").
That would look like this in D :
target("foo", {
});
I don't understand
On Friday, 30 November 2012 at 03:27:57 UTC, Walter Bright wrote:
On 11/29/2012 11:10 PM, Jonathan M Davis wrote:
[...]
You're right, I had overlooked the point that having no default
constructor means that the default construction will *always*
succeed. This is a large simplification.
Fra
On 11/30/2012 01:07 AM, r_m_r wrote:
On 11/30/2012 12:24 PM, dnewbie wrote:
Wait.. what happened to dlang-stable?
http://forum.dlang.org/thread/op.whi33qsp707...@invictus.skynet.com
https://github.com/dlang-stable/dmd/commits/master shows no commits
since July 29, 2012. I don't think any bug-
On Friday, 30 November 2012 at 03:27:57 UTC, Walter Bright wrote:
On 11/29/2012 11:10 PM, Jonathan M Davis wrote:
[...]
You're right, I had overlooked the point that having no default
constructor means that the default construction will *always*
succeed. This is a large simplification.
Fra
On 11/30/2012 12:24 PM, dnewbie wrote:
Wait.. what happened to dlang-stable?
http://forum.dlang.org/thread/op.whi33qsp707...@invictus.skynet.com
https://github.com/dlang-stable/dmd/commits/master shows no commits
since July 29, 2012. I don't think any bug-fixes from upstream got
merged into
On 11/30/2012 12:54 AM, dnewbie wrote:
Wait.. what happened to dlang-stable?
http://forum.dlang.org/thread/op.whi33qsp707...@invictus.skynet.com
No idea, looks dead. Hasn't been updated for 4 months.
I like their idea though. =P
On 11/30/2012 12:31 AM, Rob T wrote:
On Friday, 30 November 2012 at 06:05:51 UTC, 1100110 wrote:
Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit.
Gerrit triggers Jenkins to run all unit tests over the new commit.
Jenkins
reports the result back to Gerrit. If all tests are
Wait.. what happened to dlang-stable?
http://forum.dlang.org/thread/op.whi33qsp707...@invictus.skynet.com
On Friday, 30 November 2012 at 05:49:34 UTC, 1100110 wrote:
I've started work on the specification here
https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification
I'd like for someone else to start with the writeup, since I've
pretty much made my ideal known by this point.
If yo
On Friday, 30 November 2012 at 06:05:51 UTC, 1100110 wrote:
Take for example Gerrit + Jenkins: Every commit is first sent
to Gerrit.
Gerrit triggers Jenkins to run all unit tests over the new
commit. Jenkins
reports the result back to Gerrit. If all tests are green and
another
developer gives h
On 11/28/2012 09:32 AM, bearophile wrote:
Walter Bright:
I can see creating a stable D2 and a forward D2 for 6 months at a time
or so, as has been proposed here. I think that's a good idea. But only
after D1 is no longer supported.
I am OK with such ideas. Below there are some musings.
How d
Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit.
Gerrit triggers Jenkins to run all unit tests over the new commit. Jenkins
reports the result back to Gerrit. If all tests are green and another
developer gives his "Looks good to me" (lgtm) then the commit is applied to
the
On 11/29/2012 11:44 PM, Rob T wrote:
On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic wrote:
On 11/29/12, Rob T wrote:
Seriously, how many years has the D community been operating in
this way, 10 or more?
Not really, the D team switched to Git only recently (maybe 1+ years
now?).
On 11/29/2012 11:17 PM, Rob T wrote:
On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
Let's do this thing.
I can help with formulating a process and I can also help write up the
guidelines and so forth, so I'll sign up.
If we can decide on a road map and write it up, and get enough
On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic
wrote:
On 11/29/12, Rob T wrote:
Seriously, how many years has the D community been operating in
this way, 10 or more?
Not really, the D team switched to Git only recently (maybe 1+
years
now?).
If the problem here is just some
On 11/29/2012 11:17 PM, Rob T wrote:
On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
Let's do this thing.
I can help with formulating a process and I can also help write up the
guidelines and so forth, so I'll sign up.
If we can decide on a road map and write it up, and get enough
On Friday, 30 November 2012 at 05:17:20 UTC, Rob T wrote:
How many people do you think we need to get started, 5 or so?
PS: We can use ALL the help we can get, I was talking about
forming a core group of people who are responsible for moving
things forward and getting the work organized.
--
On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
Let's do this thing.
I can help with formulating a process and I can also help write
up the guidelines and so forth, so I'll sign up.
If we can decide on a road map and write it up, and get enough
consensus for implementing it, the
On Friday, 30 November 2012 at 03:27:57 UTC, Walter Bright wrote:
Frankly, non-trivial default construction has always smelled
like a bad practice to me, though it's not always obvious why.
If that's the case, then we need to get rid of postblits entirely.
They don't make sense if default-va
In the thread: Breaking D2 Language/Spec, A lot of good points were made
regarding a Stable branch for D.
A few of the requests were:(in no specific order)
Base Update and Upgrade paths on successful projects, such as Debian's
Three branches.
1. Stable branch
- Stable branch only receives bug f
On 11/29/2012 06:25 PM, js.mdnq wrote:
Simple values are ones that act atomically and use the standard
mathematical operations.
Suppose I would like to wrap an int with additional functionality:
struct SmartInt{
privatedata
int Value;
methods
}
The idea is that SmartInt semantics are treated i
On 11/29/2012 05:08 PM, js.mdnq wrote:
mixin templates seems like they could benefit from an extra parameter
that one can pass a name. The name, a string literal, sort of acts like
a preprocessor token:
mixin template InjectX!(T)
{
private T x;
T get#name#( ) { return x; }
void set#name#(T y)
{
On Friday, November 30, 2012 14:27:56 Walter Bright wrote:
> On 11/29/2012 11:10 PM, Jonathan M Davis wrote:
> > [...]
>
> You're right, I had overlooked the point that having no default
> constructor means that the default construction will *always* succeed.
> This is a large simplification.
>
>
On Friday, 30 November 2012 at 03:21:24 UTC, Walter Bright wrote:
So copying them is always an unsurprising bit copy.
Is this a speed thing, or is there a deeper reason?
If it's b/c of performance, IMO the compiler should be taking
care of figuring out such things internally, not forcing th
On 11/29/2012 11:10 PM, Jonathan M Davis wrote:
[...]
You're right, I had overlooked the point that having no default
constructor means that the default construction will *always* succeed.
This is a large simplification.
Frankly, non-trivial default construction has always smelled like a b
On 11/30/2012 2:21 PM, Walter Bright wrote:
On 11/29/2012 3:59 PM, Mehrdad wrote:
On Thursday, 29 November 2012 at 03:24:40 UTC, Walter Bright wrote:
The original idea is that there should be *no such thing* as default
construction of a struct as being anything other than T.init. The
default co
On 11/29/2012 3:59 PM, Mehrdad wrote:
On Thursday, 29 November 2012 at 03:24:40 UTC, Walter Bright wrote:
The original idea is that there should be *no such thing* as default
construction of a struct as being anything other than T.init. The
default construction of a struct should be a compile ti
On Friday, November 30, 2012 03:10:57 Manfred Nowak wrote:
> Timon Gehr wrote:
> > what module reflect imposes
>
> Thank you.
>
> It seems to be true then, that no issue would be generated if
> the compiler assumes, that Walters pragma is existent in every
> module.
So, you're suggesting that th
Timon Gehr wrote:
> what module reflect imposes
Thank you.
It seems to be true then, that no issue would be generated if
the compiler assumes, that Walters pragma is existent in every
module.
-manfred
Walter Bright wrote:
> yes, it is ambiguous, but it is not an error.
> One gets picked arbitrarily.
I did not see that it would not be erroneous. But if it is true,
then I do not see a sense in manually adding pragmas: they can
be assumed to exist.
-manfred
On 11/30/2012 12:58 AM, Andrei Alexandrescu wrote:
Because attributes attach to the declarations they enclose. A global
attribute would be something else.
Could be attached to the module declaration.
That implies that "module" no longer must be first, it could appear
elsewhere. It also impli
On 11/30/2012 1:17 AM, Andrei Alexandrescu wrote:
A possibly better approach would be e.g. to do a simple analysis of the
static constructor's use of symbols, and use that set to decide whether
two static constructors must be ordered or not.
It's not a complete solution, since using a symbol S
On 11/30/2012 5:33 AM, deadalnix wrote:
Cowabunga ! String as attribute again.
Did someone say "Wil Wheaton" 3 times?
Simple values are ones that act atomically and use the standard
mathematical operations.
Suppose I would like to wrap an int with additional functionality:
struct SmartInt{
privatedata
int Value;
methods
}
The idea is that SmartInt semantics are treated identical to
SmartInt.Value
On Thursday, 29 November 2012 at 23:31:54 UTC, Jonathan M Davis
wrote:
I'm all for T() meaning T.init if T doesn't have a static
opCall, but T()
shouldn't be guaranteed to be T.init. I'd very much like to see
code like
auto t = T();
to continue to work regardless of whether T has a static opC
On Thursday, November 29, 2012 20:07:57 Andrei Alexandrescu wrote:
> I think we either do it right or leave it as it is. It's not like
> there's no workaround so if we take a stand here we better have
> something compelling.
I think that an attribute per static constructor indicating that it had n
On Friday, November 30, 2012 01:21:06 Andrej Mitrovic wrote:
> On 11/29/12, Rob T wrote:
> > Seriously, how many years has the D community been operating in
> > this way, 10 or more?
>
> Not really, the D team switched to Git only recently (maybe 1+ years
> now?). Imo what's really lacking is (wo
On Friday, 30 November 2012 at 01:07:57 UTC, Andrei Alexandrescu
wrote:
I think we either do it right or leave it as it is. It's not
like there's no workaround so if we take a stand here we better
have something compelling.
Andrei
Finally some sanity here !
On 11/29/12 5:43 PM, Walter Bright wrote:
On 11/30/2012 12:09 AM, Daniel Murphy wrote:
I don't think this is sufficient. Imagine a group of modules that really
_do_ have a cyclic dependency, and a mixin that adds an independent
static
this. Ideally you'd be able to mark the mixed-in constructor
mixin templates seems like they could benefit from an extra
parameter that one can pass a name. The name, a string literal,
sort of acts like a preprocessor token:
mixin template InjectX!(T)
{
private T x;
T get#name#( ) { return x; }
void set#name#(T y)
{
// Checks
On 11/29/12, Rob T wrote:
> Seriously, how many years has the D community been operating in
> this way, 10 or more?
Not really, the D team switched to Git only recently (maybe 1+ years
now?). Imo what's really lacking is (wo)manpower, not the process
(which can of course always be improved).
On Thursday, 29 November 2012 at 16:51:29 UTC, Max Samukha wrote:
On Thursday, 29 November 2012 at 15:18:11 UTC, Paulo Pinto
wrote:
On Thursday, 29 November 2012 at 12:04:28 UTC, Max Samukha
wrote:
On Thursday, 29 November 2012 at 11:39:20 UTC, Paulo Pinto
wrote:
On Thursday, 29 November 2012 a
On Thursday, November 29, 2012 20:27:32 Dmitry Olshansky wrote:
> 11/29/2012 7:24 AM, Walter Bright пишет:
> > On 11/29/2012 4:47 AM, monarch_dodra wrote:
> >> On Sunday, 25 November 2012 at 16:47:08 UTC, Dmitry Olshansky wrote:
> >>> Thoughts?
> >>
> >> I don't know about "killing" T(), but I thi
On 11/30/2012 9:43 AM, Walter Bright wrote:
It is possible for each static constructor to specify independently of
the other static constructors which imports must be constructed first.
But do we really want to go that far?
One way to do that might be to borrow syntax from classes:
static t
On 11/30/2012 12:09 AM, Daniel Murphy wrote:
I don't think this is sufficient. Imagine a group of modules that really
_do_ have a cyclic dependency, and a mixin that adds an independent static
this. Ideally you'd be able to mark the mixed-in constructor as independent
without tainting the whole
On 11/29/2012 11:58 PM, Manfred Nowak wrote:
This is sufficient only for a simple cycle without any branches
or a trivial clique like the one shown. Please recall, that in a
clique every member is connected to every other member---in this
case by an import statement.
It is already not sufficient
On Thursday, November 29, 2012 23:28:07 Timon Gehr wrote:
> On 11/29/2012 01:17 PM, Jonathan M Davis wrote:
> > In the past when I've brought up similar solutions, he's been completely
> > opposed to them. ...
>
> It is not a solution, it is a workaround.
What do you mean? The runtime sees circul
On 11/29/2012 01:17 PM, Jonathan M Davis wrote:
In the past when I've brought up similar solutions, he's been completely
opposed to them.
...
It is not a solution, it is a workaround.
On Thursday, 29 November 2012 at 22:12:08 UTC, Jonathan M Davis
wrote:
The benevolent dictator model is quite common in open source
software
development. There needs to be a team to support that if you
want to really be
a team project rather than one person's pet project, and it's
not like the
On 11/29/2012 10:45 PM, deadalnix wrote:
On Thursday, 29 November 2012 at 21:43:30 UTC, Jonathan M Davis wrote:
On Thursday, November 29, 2012 21:08:58 Jacob Carlborg wrote:
BTW, how does Java handle this? And C# if it has something similar.
They just let you blow your foot off. All static va
On 11/29/2012 09:30 PM, Manfred Nowak wrote:
Max Samukha wrote:
there must not be circular dependency issues
The model shown does not force circular dependencies, because
every receiver module only imports one module: `module reflect'.
And I can not see, that this module imports any other mod
On Thursday, November 29, 2012 22:01:46 Rob T wrote:
> On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg
>
> wrote:
> > On 2012-11-29 17:12, H. S. Teoh wrote:
> >> Didn't Walter already say that if somebody steps up to do it,
> >> he would
> >> endorse it?
> >
> > Not what I've seen.
On Thursday, 29 November 2012 at 20:47:49 UTC, Jacob Carlborg
wrote:
On 2012-11-29 19:53, Rob T wrote:
Ruby would not be a runtime dependency. It's embedded in the
tool just like any other library.
OK, that's better,
If I recall correctly, you need to use that exact syntax. If
you move the f
> Actually I figured it out - rdmd can simply read its own file argument
> and look at the shebang line. Then there's no more issue of space
> coalescing, line length limitations etc.
Smart! :-)
On 11/29/12 3:48 PM, Jacob Carlborg wrote:
On 2012-11-29 16:27, Gor Gyolchanyan wrote:
Sure, but that will be part of the code, so there will still be no build
system, because the compiler will be able read the build info from the
source.
For the 10th time, how will it handle import paths?
A
On Thursday, 29 November 2012 at 21:43:30 UTC, Jonathan M Davis
wrote:
On Thursday, November 29, 2012 21:08:58 Jacob Carlborg wrote:
BTW, how does Java handle this? And C# if it has something
similar.
They just let you blow your foot off. All static variables can
be directly
initialized at ru
On 11/29/12 3:39 PM, Jacob Carlborg wrote:
On 2012-11-29 15:28, Andrei Alexandrescu wrote:
Since you think (as opposed to believe), then there are reasons. What
are those reasons, and what steps can we take to obviate them from the D
side?
Some features Ruby has that makes it less verbose to
On Thursday, 29 November 2012 at 21:36:46 UTC, deadalnix wrote:
On Thursday, 29 November 2012 at 21:19:02 UTC, Jacob Carlborg
wrote:
That's not what I've heard. Minor could be new features, as
long as they don't break anything. But that might be more for
libraries, i.e. adding a new function.
On Thursday, November 29, 2012 21:08:58 Jacob Carlborg wrote:
> BTW, how does Java handle this? And C# if it has something similar.
They just let you blow your foot off. All static variables can be directly
initialized at runtime, so it's easy to use variables before they're actually
initialized
On Thursday, November 29, 2012 16:18:10 Paulo Pinto wrote:
> On Thursday, 29 November 2012 at 12:04:28 UTC, Max Samukha wrote:
> > On Thursday, 29 November 2012 at 11:39:20 UTC, Paulo Pinto
> >
> > wrote:
> >> On Thursday, 29 November 2012 at 03:19:55 UTC, Andrei
> >>
> >> Alexandrescu wrote:
> >
On Thursday, 29 November 2012 at 21:19:02 UTC, Jacob Carlborg
wrote:
That's not what I've heard. Minor could be new features, as
long as they don't break anything. But that might be more for
libraries, i.e. adding a new function.
Exactly.
On 11/29/12 3:27 PM, foobar wrote:
Huh?
I made the exact same observation you did that module declarations can
also carry attributes. You completely ignored the main part of my post
regarding what I feel would indeed be a better approach (IMO).
I don't understand why you bother to answer a post
On 2012-11-29 21:36, Rob T wrote:
On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
Isn't this only necessary if the new feature depends on said breaking
changes? If not, it can be safely merged in. If it's a trivial
On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg
wrote:
On 2012-11-29 17:12, H. S. Teoh wrote:
Didn't Walter already say that if somebody steps up to do it,
he would
endorse it?
Not what I've seen. At least not something more in those words.
What's needed is a core team of dec
On Thursday, 29 November 2012 at 00:16:28 UTC, deadalnix wrote:
Can someone remember me why this ended up in master ? This
feature is clearly not ready.
Please, read this thread, esp towards the end.
"Breaking D2 language/spec changes with D1 being discontinued in
a month"
The current lack
On 2012-11-29 17:12, H. S. Teoh wrote:
Didn't Walter already say that if somebody steps up to do it, he would
endorse it?
Not what I've seen. At least not something more in those words.
--
/Jacob Carlborg
On 2012-11-29 18:35, Andrei Alexandrescu wrote:
There are plenty of patterns for solving order of initialization issues
in libraries, known since time immemorial. Requiring a library
initialization call would be the simplest (albeit not the most elegant).
The Monostate and Singleton patterns als
On 2012-11-29 20:48, Andrei Alexandrescu wrote:
You can't say that. They do work don't they.
I think he means, not for the use cases we discuss here.
--
/Jacob Carlborg
On 2012-11-29 16:27, Gor Gyolchanyan wrote:
Sure, but that will be part of the code, so there will still be no build
system, because the compiler will be able read the build info from the
source.
For the 10th time, how will it handle import paths?
--
/Jacob Carlborg
On 2012-11-29 19:53, Rob T wrote:
The very last thing I would want to do is to futz around installing Ruby
and learning Ruby for the sole purpose of building a D application.
Ruby would not be a runtime dependency. It's embedded in the tool just
like any other library. BTW, I never heard anyo
On 2012-11-29 15:28, Andrei Alexandrescu wrote:
Since you think (as opposed to believe), then there are reasons. What
are those reasons, and what steps can we take to obviate them from the D
side?
Some features Ruby has that makes it less verbose to use:
* No semicolons
* Calling a method wit
On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
Isn't this only necessary if the new feature depends on said
breaking
changes? If not, it can be safely merged in. If it's a trivial
change
like a syntax change, the
Max Samukha wrote:
> there must not be circular dependency issues
The model shown does not force circular dependencies, because
every receiver module only imports one module: `module reflect'.
And I can not see, that this module imports any other module.
Therefore `module relect' and its `impo
On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei
Alexandrescu wrote:
On 11/29/12 6:44 AM, foobar wrote:
On Thursday, 29 November 2012 at 10:25:40 UTC, Walter Bright
wrote:
On 11/29/2012 6:40 PM, Jacob Carlborg wrote:
On 2012-11-29 03:00, Walter Bright wrote:
An attribute would bring alon
On 2012-11-29 16:58, Andrei Alexandrescu wrote:
That's workable. I'm hoping, however, to make benchmarks as easy and as
trivial to define as unittests.
Unit tests have the same problem. One need to create a module containing
a main function and importing the modules one wants to benchmark/tes
On 2012-11-29 19:17, deadalnix wrote:
That is understood, but Let me explain how I see things.
We are here adding yet a new feature, however small. Nothing stabilize
when adding new feature all the time.
The annoyance exist, is real, but is not THAT bad, and 'm pretty sure
the proposed solutio
On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
Isn't this only necessary if the new feature depends on said
breaking
changes? If not, it can be safely merged in. If it's a trivial
change
like a syntax change, the stable maintainer can simply fix it
by hand
and merge it in any
>
> I'm trying to find a safe spot in the middle of a file, where I can start
> parsing, normally you have to parse the entire file to understand it, ex
> with your grammar files, there are many keywords inside huge strings, so
> basically I let the compiler handle comments and white-space parsing,
On 11/29/12 2:35 PM, Max Samukha wrote:
On Thursday, 29 November 2012 at 17:35:43 UTC, Andrei Alexandrescu wrote:
On 11/29/12 12:07 PM, Max Samukha wrote:
On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei Alexandrescu
wrote:
On 11/29/12 10:17 AM, Max Samukha wrote:
On Thursday, 29 Novembe
On 11/29/2012 01:52 AM, Jonathan M Davis wrote:
On Thursday, November 29, 2012 08:45:53 Jacob Carlborg wrote:
On 2012-11-29 01:50, Walter Bright wrote:
Something has to be the default, and that dates back to when D was only
implemented on 32 bit targets.
How about defaulting to the architectu
On Thursday, 29 November 2012 at 17:35:43 UTC, Andrei
Alexandrescu wrote:
On 11/29/12 12:07 PM, Max Samukha wrote:
On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei
Alexandrescu wrote:
On 11/29/12 10:17 AM, Max Samukha wrote:
On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei
Alexandres
On Thu, Nov 29, 2012 at 08:08:08PM +0100, Joseph Rushton Wakeling wrote:
> On 11/28/2012 08:02 PM, 1100110 wrote:
> >A new module in Phobos is highly unlikely to break anything, So I
> >would assume that this would count as a simple bug fix and be merged.
>
> I don't really see that. Yes, new fun
11/29/2012 11:08 PM, Joseph Rushton Wakeling пишет:
On 11/28/2012 08:02 PM, 1100110 wrote:
A new module in Phobos is highly unlikely to break anything, So I
would assume
that this would count as a simple bug fix and be merged.
I don't really see that. Yes, new functionality _per se_ is not go
On 11/28/2012 08:02 PM, 1100110 wrote:
A new module in Phobos is highly unlikely to break anything, So I would assume
that this would count as a simple bug fix and be merged.
I don't really see that. Yes, new functionality _per se_ is not going to break
anything, but its implementation may be
On Thursday, 29 November 2012 at 18:42:17 UTC, Maxim Fomin wrote:
On Thursday, 29 November 2012 at 15:14:51 UTC, monarch_dodra
wrote:
I investigating some weird behavior regarding arrays of const
object. I'm not 100% sure what I'm observing, but it would
appear that when adding objects to a con
On Thursday, 29 November 2012 at 14:04:32 UTC, Jacob Carlborg
wrote:
I still think it's possible to have a smaller, less verbose and
more simplistic build scripts written in Ruby. BUT I would
choose a proper build tool with build scripts written in D any
day over having to use shell scripts or
On Thursday, 29 November 2012 at 15:14:51 UTC, monarch_dodra
wrote:
I investigating some weird behavior regarding arrays of const
object. I'm not 100% sure what I'm observing, but it would
appear that when adding objects to a const array, objects are
not postblit-ed? Is this the expected behavi
On Thursday, 29 November 2012 at 16:51:31 UTC, Iain Buclaw wrote:
On 27 November 2012 21:42, Walter Bright
wrote:
On 11/27/2012 10:37 PM, Iain Buclaw wrote:
As far as I can tell, it's all just metadata known at
compile-time
only. Nothing is written in the resultant binaries or object
files
On Thursday, 29 November 2012 at 17:12:29 UTC, jerro wrote:
The original idea is that there should be *no such thing* as
default construction of a struct as being anything other than
T.init. The default construction of a struct should be a
compile time creature, not a runtime one.
Any methods
On Thursday, 29 November 2012 at 12:10:06 UTC, Maxim Fomin wrote:
On Thursday, 29 November 2012 at 10:41:46 UTC, Mehrdad wrote:
I'm just not understanding the whole "the default construction
of a struct should be a compile time creature, not a runtime
one".
Don't you have to initialize the
On Thursday, 29 November 2012 at 12:17:49 UTC, Jonathan M Davis
wrote:
Basic features in the language require static constructors
(e.g. static
variables frequently do), and some things just can't be done
without them.
Andrei's std.benchmark proposal actually doesn't work, because
in order to do
monarch_dodra:
However, if we change "S[] arr;" to "const(S)[] arr;", then the
output becomes:
//
0
1
2
3
4
//
Strange... right?
I think it's a known problem of the postblit. It was discussed
recently.
Bye,
bearophile
11/29/2012 8:16 PM, monarch_dodra пишет:
On Thursday, 29 November 2012 at 15:14:51 UTC, monarch_dodra wrote:
Thoughts?
I give up:
//
RCI[] arr3 = [RCI(0), RCI(1)];
foreach(i; 0 .. 2)
assert(arr3[i] == i);
//
I think I've seen it before. The problem is in the array
11/29/2012 9:12 PM, jerro пишет:
The original idea is that there should be *no such thing* as default
construction of a struct as being anything other than T.init. The
default construction of a struct should be a compile time creature,
not a runtime one.
Any methods or workarounds to try and mak
On 29/11/2012 16:27, Dmitry Olshansky wrote:
11/29/2012 7:24 AM, Walter Bright пишет:
The original idea is that there should be *no such thing* as default
construction of a struct as being anything other than T.init. The
default construction of a struct should be a compile time creature, not
a r
On 11/29/12 12:07 PM, Max Samukha wrote:
On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei Alexandrescu wrote:
On 11/29/12 10:17 AM, Max Samukha wrote:
On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei Alexandrescu
wrote:
I think this entire approach is unprincipled (aside from solvin
The original idea is that there should be *no such thing* as
default construction of a struct as being anything other than
T.init. The default construction of a struct should be a
compile time creature, not a runtime one.
Any methods or workarounds to try and make T() produce
something differ
On Thursday, 29 November 2012 at 15:23:32 UTC, Andrei
Alexandrescu wrote:
On 11/29/12 10:17 AM, Max Samukha wrote:
On Thursday, 29 November 2012 at 14:17:40 UTC, Andrei
Alexandrescu wrote:
I think this entire approach is unprincipled (aside from
solving a
problem that's not urgent and not im
On 26/11/2012 19:59, Walter Bright wrote:
On 11/27/2012 5:52 AM, David Nadlinger wrote:
I agree, and if I remember previous discussions on the subject
correctly, it seems like only Walter is in favor of upholding the
current restrictions of "alias" parameters to symbols. I simply do not
see a po
Iain Buclaw:
suppose this may open a door to implement
compiler-specific UDAs:
["gcc.flatten"]
int foobar()
{
}
Maybe an enum is better:
[GccFlags.flatten]
int foobar() {
}
Bye,
bearophile
1 - 100 of 162 matches
Mail list logo
