On 02.12.2014 23:20, Vladimir Panteleev wrote:
DSource in the headlines? In 2014? Shocking, I know.
Since Brad is no longer an active D user, and the website has had spotty
uptime lately, I've offered to take over the hosting and any maintenance.
Although opinions exist that the site should
I removed all the harder challenges, so y'all can now stop
complaining. Sorry.
There are now only 2 simple questions. Pull requests welcome.
On Thursday, 4 December 2014 at 02:48:07 UTC, MattCoder wrote:
On Tuesday, 2 December 2014 at 21:41:28 UTC, Vladimir Panteleev
wrote:
Although forum.dlang.org has had a spam check and used
reCAPTCHA since it was announced, it is only somewhat
effective against fully-automated bots - it is
On Thursday, 4 December 2014 at 02:29:39 UTC, Faux Amis wrote:
This has to be a joke!
I couldn't answer a single question:
What is the name of the D language syntax feature illustrated
in the following fragment of D code?
string a = x5095 f9 95d723c2;
Seems like hex to me
What is the name
On Wednesday, 3 December 2014 at 19:42:39 UTC, Ary Borenszweig
wrote:
On 12/2/14, 6:41 PM, Vladimir Panteleev wrote:
Enter DCaptcha
I think this could work with just two or three variants of a
question. Always ask what's the return value of the function.
1. int foo() { return 8 % 3; }
I
On Thursday, 4 December 2014 at 04:02:49 UTC, Mike wrote:
I had to maintain a technical forum last year that was getting
spammed like crazy. I added the question how many bits are in
a byte?, and the spam vanished. Based on that experience, I
think the bar can be set very low.
The Wiki had
On Thursday, 4 December 2014 at 08:04:05 UTC, Rainer Schuetze
wrote:
On 02.12.2014 23:20, Vladimir Panteleev wrote:
DSource in the headlines? In 2014? Shocking, I know.
Since Brad is no longer an active D user, and the website has
had spotty
uptime lately, I've offered to take over the
On Thursday, 4 December 2014 at 08:20:27 UTC, Kagamin wrote:
On Thursday, 4 December 2014 at 02:29:39 UTC, Faux Amis wrote:
tries to differentiate between human wanting to learn D and one
not wanting.
the latter is just a myth...
On Thursday, 4 December 2014 at 05:53:28 UTC, Olagsfark wrote:
Thanks for the help gary, i guess i'll have to install git.
No worries, once you get over the learning curve git + git-hub
are really cool. :)
On Thursday, 4 December 2014 at 10:39:25 UTC, eles wrote:
On Thursday, 4 December 2014 at 08:20:27 UTC, Kagamin wrote:
On Thursday, 4 December 2014 at 02:29:39 UTC, Faux Amis wrote:
tries to differentiate between human wanting to learn D and
one not wanting.
the latter is just a myth...
Just re-posting in case there is people here that are not subscribed to
the D general group (like me ;).
http://forum.dlang.org/post/yyfeeqiuuepuzhjvk...@forum.dlang.org
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
On Friday, 28 November 2014 at 16:39:38 UTC, Basile Burg wrote:
Hello, a new release of Coedit[MainPage], the small open-source
D
IDE for Windows and Linux, is released. Here is a paste of the
release log.
Messages:
=
- redesigned the widget: a toolbar at the top allows to filter
the
On Thursday, 4 December 2014 at 21:53:26 UTC, Mehmet wrote:
On Friday, 28 November 2014 at 16:39:38 UTC, Basile Burg wrote:
Hello, a new release of Coedit[MainPage], the small
open-source D
IDE for Windows and Linux, is released. Here is a paste of the
release log.
Messages:
=
-
On 2014-12-03 21:58, Walter Bright wrote:
Should be up now.
Yes, thanks.
--
/Jacob Carlborg
On 2014-12-04 02:10, Martin Nowak wrote:
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and the current solution still isn't great [1].
This idea here achieves
- fine grained control over log levels
On 12/4/2014 12:12 AM, Jacob Carlborg wrote:
On 2014-12-03 21:58, Walter Bright wrote:
Should be up now.
Yes, thanks.
welcs
On Thursday, 4 December 2014 at 06:24:35 UTC, Suminda Dharmasena
wrote:
What I am saying is, if it is introduced in D it should be more
flexible than Rust.
This isn't the first post of you who makes me think that you're a
troll but I'll answer anyway.
Having types for static memory safety
On Thursday, 4 December 2014 at 01:10:43 UTC, Martin Nowak wrote:
```d
module mypkg.foo.bar;
public import mypkg.logLevel;
void baz(T)(T t)
{
info(baz);
}
```
Not bad. Does info=baz compile?
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds the missing
semantics for the 'scope' storage class in order to make it possible to pass a
reference to a function without it being possible for it to escape.
This, among other things, makes a ref
On Thu, 04 Dec 2014 01:24:13 -0800
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds the missing
semantics for the 'scope' storage class in order to make it possible to pass
a
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds
the missing semantics for the 'scope' storage class in order to
make it possible to pass a reference to a function without it
being
On 12/4/2014 1:53 AM, ketmar via Digitalmars-d wrote:
cosmetic issue: some comments are referring to rules by number (Error,
rule 5), yet the rules aren't explicitly numbered. not a big deal, but
still somewhat hard to follow.
Yeah, still learning wiki markup!
On 12/4/2014 1:51 AM, eles wrote:
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds the missing
semantics for the 'scope' storage class in order to make it possible to pass a
reference to
On Thursday, 4 December 2014 at 10:00:37 UTC, Walter Bright wrote:
On 12/4/2014 1:51 AM, eles wrote:
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright
wrote:
http://wiki.dlang.org/DIP69
Was afraid that would break too much code.
An annotation for functions could make all
On Thu, 04 Dec 2014 10:04:07 +
eles via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Thursday, 4 December 2014 at 10:00:37 UTC, Walter Bright wrote:
On 12/4/2014 1:51 AM, eles wrote:
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright
wrote:
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg
wrote:
On 2014-12-04 02:10, Martin Nowak wrote:
I just found a very compelling alternative solution to the
LogLevel
disabling problem. This was one of the reasons for the delay
of std.log
and the current solution still isn't great
thank you for pushing on this.
Lifetime last bullet point: , but lower than any variables in
higher scopes.
isn't that redundant to the first bullet point? Or am I missing
something?
Scope affects variables according to these rules:
Could you enumerate the list instead of bullet points, I
On Thursday, 4 December 2014 at 08:42:36 UTC, Kagamin wrote:
Not bad. Does info=baz compile?
That's not my business, if it's callable with a single argument,
it would work, but it's not @property.
On Thursday, 4 December 2014 at 10:11:25 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 04 Dec 2014 10:04:07 +
eles via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Thursday, 4 December 2014 at 10:00:37 UTC, Walter Bright
wrote:
On 12/4/2014 1:51 AM, eles wrote:
On Thursday, 4
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but rather
__MODULE__ ~ _loggerinfo.d and then describe the import
constraint in the documentation.
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds
the missing semantics for the 'scope' storage class in order to
make it possible to pass a reference to a function without it
being
On Thursday, 4 December 2014 at 10:16:52 UTC, Martin Nowak wrote:
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg
hack. I have stopped following the std.log thread, could you
summarize what issues you're having and trying to solve and
why not a more obvious solution doesn't work?
As I have explained countless times, the configuration in source
and through inheritance will always be more powerful and flexible
than a config file. I'm not gone create any config file support,
as there will be always one feature missing and there is just no
way to anticipate all possible
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ _loggerinfo.d and then describe the
import constraint in the documentation.
Good idea,
On Thursday, 4 December 2014 at 10:56:29 UTC, Robert burner
Schadek wrote:
As I have explained countless times, the configuration in
source and through inheritance will always be more powerful and
There is no contradiction. Configuration is level 1,
implementation is level 2.
On Thursday, 4 December 2014 at 10:44:22 UTC, Ola Fosheim Grøstad
wrote:
I like the direction you are taking, but I think the better
solution is to have:
It's a nice idea for generic feature testing flags, but it's a
lot of implementation work in the compiler. And it seems odd to
implement a
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ _loggerinfo.d and then describe the
import constraint in the documentation.
Importing a
Errors for scope violations are only reported in @safe code.
Why? If I've explicitly designated a reference as scope, why
should it be ignored in un-@safe code?
On Thursday, 4 December 2014 at 11:02:39 UTC, Martin Nowak wrote:
It's a nice idea for generic feature testing flags, but it's a
lot of implementation work in the compiler. And it seems odd to
implement a big part of a library in the compiler.
I think D lacks a generic project configuration
On Thursday, 4 December 2014 at 11:21:27 UTC, Marc Schütz wrote:
Errors for scope violations are only reported in @safe code.
Why? If I've explicitly designated a reference as scope, why
should it be ignored in un-@safe code?
Agreed, it should also work for any other code with some function
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Great stuff.
Will this be possible, it's a fairly important use-case.
scope ref T setVal(scope ref T t)
{
t.val = 12;
return t;
}
Another question, how would a reference counted pointer
On Thursday, 4 December 2014 at 11:02:23 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 December 2014 at 10:56:29 UTC, Robert burner
Schadek wrote:
As I have explained countless times, the configuration in
source and through inheritance will always be more powerful and
There is no
On Thursday, 4 December 2014 at 11:49:53 UTC, Ola Fosheim Grøstad
wrote:
I think D lacks a generic project configuration mechanism. I
generally want configurations to be located in one or at least
a few files that are easy to modify and which can have tools
written for them. So yes, this
On Thursday, 4 December 2014 at 11:12:02 UTC, Martin Nowak wrote:
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ _loggerinfo.d and then
On Thursday, 4 December 2014 at 12:16:54 UTC, Robert burner
Schadek wrote:
I think D lacks a good std.serialization module
That would be a good point if you did binary logging…
Hi All,
I am a Berlin based D developer who has been working with D for
about 2 and a half years. Like other more well known names in
these forums I work for a company called Sociomantic.
I am interested in organizing some meetups for D programmers in
the nearby area. The first of these
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
How inout fits the picture? It has some scope semantics too.
Section about expressions suggests you will tack scoping
carefully, but then why would you need return by ref tricks,
which don't rely
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds
the missing semantics for the 'scope' storage class in order to
make it possible to pass a reference to a function without it
being
I am not expert in such things, but here are few comments and
questions.
Errors for scope violations are only reported in @safe code.
This seems acceptable only if the compiler switch -scope
implies functions to be @safe by default and @system on request,
because currently lot of D
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Hi All,
I am a Berlin based D developer who has been working with D for
about 2 and a half years. Like other more well known names in
these forums I work for a company called Sociomantic.
I am interested in organizing some meetups for
It's an argument for Java over Python specifically but a bit more
general in reality. This stood out for me:
!…other languages like D and Go are too new to bet my work on.
http://www.teamten.com/lawrence/writings/java-for-everything.html
--
Russel.
How would this be handled in the current proposal?
class C
{
int bar(ref T); // -- inferred to be scope
}
class D : C
{
override int bar(ref T); // -- inferred to be NOT scope (but
cannot remove scope when overriding)
}
Attribute inference only works for function literals and template
On 03/12/2014 23:02, Martin Nowak wrote:
On 11/27/2014 10:30 AM, Gary Willoughby wrote:
There seems to be an effort to resurrect ctags[1] so i've taken the D
language support from this patch and applied it to the newly resurrected
ctags.
[1]: https://github.com/fishman/ctags
How about making
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit
more general in reality.
A fun read, and I see his POV. It is a pity Python does not
include some static typing, but I think he undervalues the
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit
more
general in reality. This stood out for me:
!…other languages like D and Go are too new to bet my work on.
Finally got a look at your proposal. While I do agree with many
initial statements and, specifically, proposal for heap
segregation, proposed semantics of `owned` does leave me
skeptical. It is effectively a more refined/mature approach to
cooking of immutables concept and Marc proposal, while
I think it is a better default, at least in absence of multiple
release flavors.
On Thursday, 4 December 2014 at 14:12:34 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit
more general in reality.
A fun read, and I see his POV. It is a pity
I disagree that `traits` and `constraints` are the same.
Constraint is a specific case of a trait which returns boolean
value and has semantical from of `isSomething`. Trait is pretty
much any static reflection utility, whatever it does.
Hi,
MathJax is a Javascript trick that can nicely typeset
mathematical equations written in TeX, on-the-fly, in any HTML
document. Enabling it is easily done by adding some script
.../script in the head, which I managed to do by overriding
DDOC. However, if I have a piece of code like
///
Martin Nowak wrote in message news:m5ocaj$2i8t$1...@digitalmars.com...
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and the current solution still isn't great [1].
This idea here achieves
- fine
On Thursday, 4 December 2014 at 13:10:20 UTC, Stefan wrote:
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Let me know if you are interested in taking part in this or
any future Berlin based events.
Hi, another Sociomantic developer checking in. This sounds like
a great idea, I
On Thursday, 4 December 2014 at 14:25:52 UTC, Paulo Pinto wrote:
I rather pay for just one instance.
That depends. What makes Go and Python attractive on AppEngine is
the fast spin up time, you only pay for 15 minutes, and it scales
up to 100 instances transparently. With java you need
Walter Bright wrote in message news:m5p99m$luk$1...@digitalmars.com...
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds the missing
semantics for the 'scope' storage class in order to make it possible to
pass a reference to a function without it
On Thursday, 4 December 2014 at 14:28:47 UTC, Dicebot wrote:
I think it is a better default, at least in absence of multiple
release flavors.
I don't think it's going to happen. The arguments would need to
overrule Walter Bright and Martin Nowak (effectively Druntime's
current maintainer).
On 12/4/14 4:24 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds the
missing semantics for the 'scope' storage class in order to make it
possible to pass a reference to a function without it being possible for
it to escape.
On Thursday, 4 December 2014 at 14:40:10 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 December 2014 at 14:25:52 UTC, Paulo Pinto
wrote:
I rather pay for just one instance.
That depends. What makes Go and Python attractive on AppEngine
is the fast spin up time, you only pay for 15 minutes,
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
Just for fun, I've decided to try and get MicroEmacs in D added
to the dub registry. The last time it compiled was 2 years ago.
I wound up with at least a dozen references to Phobos names
that have disappeared. No corrective
On 12/4/14 4:24 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds the
missing semantics for the 'scope' storage class in order to make it
possible to pass a reference to a function without it being possible for
it to escape.
There can be at most one owner for any piece of data.
This doesn't seem right. For GC data, the GC owns the data,
that is true. But for Ref-counted data, there is more than one
owner, and only when all the owners disown the data can it be
destroyed.
I think there is a disconnect here, you
On Thursday, 4 December 2014 at 15:04:44 UTC, Paulo Pinto wrote:
On Thursday, 4 December 2014 at 14:40:10 UTC, Ola Fosheim
Grøstad wrote:
PyPy has now 10 year of research spent into it, and it still
doesn't support all Python features.
Armin Rigo is a smart guy, but well, some things are
On Monday, 1 December 2014 at 02:44:24 UTC, Walter Bright wrote:
D's module system is very good at avoiding name collisions, and
dealing with them when they do arise.
Really laughed here. dstep got broken when going from 2.065 to
2.066 exactly because new symbol was added to object.d and it
On Tuesday, 2 December 2014 at 22:02:23 UTC, H. S. Teoh via
Digitalmars-d wrote:
However, there are major issues with scoped imports currently,
that make this otherwise ideal solution less-than-ideal, which
stem from
the way 'import' is implemented in D. When the compiler
encounters an
I would like to take part, i won't be in the area at that time.
Hoping for the next time.
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Hi All,
I am a Berlin based D developer who has been working with D for
about 2 and a half years. Like other more well known names in
these
On Wednesday, 3 December 2014 at 13:34:42 UTC, Jacob Carlborg
wrote:
On 2014-12-02 23:00, H. S. Teoh via Digitalmars-d wrote:
I'm finding it harder and harder to accept Walter's stance
that symbol
lookups should be kept simple and free from complications and
convoluted
corner cases, etc..
int* bar(scope int*);
scope int* foo();
bar(foo()); // Ok, lifetime(foo()) lifetime(bar())
I'm trying to understand how foo can be implemented in any case. It has
no scope ints to return, so where does it get the int from?
I don't see where the proposal defines what exactly can be
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Hi All,
I am a Berlin based D developer who has been working with D for
about 2 and a half years. Like other more well known names in
these forums I work for a company called Sociomantic.
I am interested in organizing some meetups for
Please no additional 3d-party dependencies for D core tool stack.
On Thursday, 4 December 2014 at 14:39:07 UTC, Vladimir Panteleev
wrote:
On Thursday, 4 December 2014 at 14:28:47 UTC, Dicebot wrote:
I think it is a better default, at least in absence of
multiple release flavors.
I don't think it's going to happen. The arguments would need to
overrule
It is all solved by semver and release discipline - something
language authors are strongly against.
On 12/4/14 10:06 AM, Tobias Pankrath wrote:
So if you have multiple ref-counted slices to an array, no one owns the
array until the ref-count goes down to 1. Question remains, if this is a
definition of ownership we want to employ.
This is like saying you have multiple owners :) I don't see
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
Perhaps better:
void foo(int[2]) {}
void bar(scope int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
Bye,
bearophile
On Thursday, 4 December 2014 at 15:29:58 UTC, Martin Nowak wrote:
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
I am interested in organizing some meetups for D programmers
in the nearby area. The first of these will be very informal
and involve a social meeting at a cafe or bar to
On Thursday, 4 December 2014 at 13:10:20 UTC, Stefan wrote:
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Hi All,
I am a Berlin based D developer who has been working with D
for about 2 and a half years. Like other more well known names
in these forums I work for a company called
Why when an DMD developer said « no » to you in ticket you go to
the forum and troll there ?
If one wants debug information he will use debug version of
phobos. In fine-tune application there's no need for -gs flag.
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Let me know if you are interested in taking part in this or any
future Berlin based events.
Count me in!
On 12/4/14, 10:47 AM, Russel Winder via Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit more
general in reality. This stood out for me:
!…other languages like D and Go are too new to bet my work on.
On 12/4/14, 2:11 PM, Ary Borenszweig wrote:
On 12/4/14, 10:47 AM, Russel Winder via Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit more
general in reality. This stood out for me:
!…other languages like D and Go are too new to bet my work on.
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit
more
general in reality. This stood out for me:
!…other languages like D and Go are too new to bet my work on.
On Thu, Dec 04, 2014 at 01:57:43AM -0800, Walter Bright via Digitalmars-d wrote:
On 12/4/2014 1:53 AM, ketmar via Digitalmars-d wrote:
cosmetic issue: some comments are referring to rules by number
(Error, rule 5), yet the rules aren't explicitly numbered. not a
big deal, but still somewhat
On Thu, Dec 04, 2014 at 10:31:07AM -0800, H. S. Teoh via Digitalmars-d wrote:
On Thu, Dec 04, 2014 at 01:57:43AM -0800, Walter Bright via Digitalmars-d
wrote:
On 12/4/2014 1:53 AM, ketmar via Digitalmars-d wrote:
cosmetic issue: some comments are referring to rules by number
(Error, rule
On Thu, Dec 04, 2014 at 01:49:06PM +, Tobias Pankrath via Digitalmars-d
wrote:
How would this be handled in the current proposal?
class C
{
int bar(ref T); // -- inferred to be scope
}
class D : C
{
override int bar(ref T); // -- inferred to be NOT scope (but cannot
remove
On Thu, Dec 04, 2014 at 01:24:13AM -0800, Walter Bright via Digitalmars-d wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds the
missing semantics for the 'scope' storage class in order to make it
possible to pass a reference to a function
04-Dec-2014 18:32, Dicebot пишет:
Please no additional 3d-party dependencies for D core tool stack.
What are current 3rd-party deps? Dependency on DMC make and compiler is
already there, GNU make is not installed by default on FreeBSD.
What would you suggest we do?
--
Dmitry Olshansky
On 12/4/2014 3:21 AM, Marc Schütz schue...@gmx.net wrote:
Errors for scope violations are only reported in @safe code.
Why? If I've explicitly designated a reference as scope, why should it be
ignored in un-@safe code?
To interface to code that presents a safe interface, but does things
On 12/4/2014 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
Please fix the comment. ;-)
done
On 12/4/2014 6:58 AM, Steven Schveighoffer wrote:
This doesn't seem right. For GC data, the GC owns the data, that is true. But
for Ref-counted data, there is more than one owner, and only when all the owners
disown the data can it be destroyed.
I think there is a disconnect here, you can't say
On 12/4/2014 4:55 AM, bearophile wrote:
I am not expert in such things, but here are few comments and questions.
Errors for scope violations are only reported in @safe code.
This seems acceptable only if the compiler switch -scope implies functions to
be @safe by default and @system on
On 12/4/2014 4:03 AM, Martin Nowak wrote:
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Great stuff.
Will this be possible, it's a fairly important use-case.
scope ref T setVal(scope ref T t)
{
t.val = 12;
return t;
}
Yes, it
On 12/4/2014 4:56 AM, Kagamin wrote:
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
How inout fits the picture? It has some scope semantics too.
s/inout/ref/
Section about expressions suggests you will tack scoping carefully, but then
why
1 - 100 of 219 matches
Mail list logo
