On Wednesday, 30 August 2017 at 14:05:40 UTC, Mark wrote:
I see that in the previous review rounds some people suggested
various keywords for designating the return value of a function
("return", "result", ...) in an `out` contract. What about
using a plain old underscore? For example:
int
On Monday, 31 July 2017 at 09:55:22 UTC, Nick Treleaven wrote:
This is subjective. If you put `do` on the end of the line, it
is trivial:
in(x > 4)
out(works)
out(r; r.test)
out(flag) do
{
// body
}
The common case is for `out` contracts to test for the return
variable. Something like 90%
On Friday, 28 July 2017 at 11:04:23 UTC, Nick Treleaven wrote:
One option to solve the out contract ambiguity and aid parsing
by tools is to require 'do' after out contract expressions. It
allows the syntax `out(expression) do {...}`, even when
expression is a single identifier that should be
On Tuesday, 25 July 2017 at 07:48:39 UTC, Andrea Fontana wrote:
I don't like it so much but also something like this could be
considered:
out!(x => x>0)
or maybe:
out!x(x > 0)
that can't collide with current syntax
Andrea
It's another viable option, but it doesn't seem to stand out much
On Wednesday, 26 July 2017 at 08:12:39 UTC, Olivier FAURE wrote:
I... think you misunderstood me? I shouldn't have used the word
'proposals', I should have said 'suggestions'.
What I meant was "I think it would be better for the current
version of DIP 1009 to include a 'Rejected alternative
On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:
However, I think the presentation of the DIP needs some work.
For example, the rationales and lines of reasoning that
eventually led to the currently proposed syntax, both from the
original draft of this DIP and from the ensuing
On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:
In short, I feel that a more substantial discussion of how we
arrived at the current form of the proposal is important so
that Walter & Andrei can have the adequate context to
appreciate the proposed syntax changes, and not feel like
On Saturday, 22 July 2017 at 03:05:55 UTC, aberba wrote:
How about this in current syntax? (that's what I do)
int func(int a)
in
{
assert(a >= 0);
}
out(result)
{
assert(result >= 2);
}
body
{
return 2 * a;
}
an improvement could be:
int func(int
On Friday, 21 July 2017 at 18:55:08 UTC, Moritz Maxeiner wrote:
I really like how the syntax turned out. My only remaining
peeve is the `ContractParameters` nomenclature in the grammar
section, because it implies that asserts are contracts.
Maybe I should have stuck with AssertParameters.
On Friday, 21 July 2017 at 15:13:09 UTC, Timon Gehr wrote:
"in and out expressions must come at the end of the function
declarator suffix, and before the regular contracts, if any"
The implementation actually allows all possible notations for
contracts to be mixed freely. Whether or not 'do'
On Wednesday, 28 June 2017 at 14:33:52 UTC, Moritz Maxeiner wrote:
The DIP is still at pre-preliminary review round 1 (since it
hasn't finished yet).
The current syntax proposal is effectively emergent through H.
S. Teoh's general proposal [1], Solomon E's out enhancement
[2], and Timon Gehr's
On Wednesday, 28 June 2017 at 01:23:18 UTC, MysticZach wrote:
On Tuesday, 27 June 2017 at 09:18:11 UTC, Olivier FAURE wrote:
A bit late to the party, but I would recommend the following
syntax:
out (void; myTest)
for argument-less tests. A casual reader would be less likely
to see this
On Tuesday, 27 June 2017 at 09:18:11 UTC, Olivier FAURE wrote:
A bit late to the party, but I would recommend the following
syntax:
out (void; myTest)
for argument-less tests. A casual reader would be less likely
to see this in code and think it's some sort of typo; it would
be easier
On Monday, 26 June 2017 at 21:06:10 UTC, Timon Gehr wrote:
The DIP is missing the corresponding syntax for invariants:
class C{
private int x=1;
invariant(x>0, "x must stay positive");
}
Implementation:
https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax
Well done. It
On Sunday, 25 June 2017 at 12:10:02 UTC, Timon Gehr wrote:
The path of least resistance is to use existing language
constructs, i.e.
out result => assert(result > 0)
Andrei
This would face quite some resistance, on the following grounds:
out(result){ assert(result > 0); } // exists
out
On Saturday, 24 June 2017 at 12:26:57 UTC, Moritz Maxeiner wrote:
Should the need ever arise for (new) contract and assert
grammar to diverge it can be dealt with then by whoever does
the diverging.
Yes, I'll keep the grammar the same for now, because there is a
benefit to doing so, in that
On Saturday, 24 June 2017 at 02:31:09 UTC, Solomon E wrote:
I think my proposal to add another use of semicolon in
parentheses, like `foreach` or `for` but not the same as
either, was needlessly complicated.
It's very popular, actually. :)
in (a)
out (result) (a)
This resembles template
On Friday, 23 June 2017 at 21:36:07 UTC, Moritz Maxeiner wrote:
Contracts within the DbC paradigm *are* abstractions that do
not necessitate any particular implementation.
In practice, though, what must any such implementation actually
achieve?
1. allow the source code to express its intent
On Friday, 23 June 2017 at 20:49:35 UTC, Moritz Maxeiner wrote:
Normal usage of the new syntax? If asserts later on get a
(possibly breaking) syntax overhaul that will affect (and
forward breakage to) the contract syntax, as well, if it uses
the same compiler infrastructure.
I believe this
On Friday, 23 June 2017 at 20:03:17 UTC, Moritz Maxeiner wrote:
No. Asserts are the meat of in/out contracts, these are
actually asserts. Anything you do to the assert grammar
should be done here as well.
I agree. I can understand wanting to pass in/out violations to
a different handler
On Friday, 23 June 2017 at 18:42:55 UTC, Steven Schveighoffer
wrote:
On 6/23/17 2:24 PM, Moritz Maxeiner wrote:
I'm all for this syntax, just one spec/implementation question:
If the new contract syntax (formally) shares grammar rules
with assert, won't that cause more work for people who want
On Friday, 23 June 2017 at 18:20:23 UTC, Moritz Maxeiner wrote:
On Friday, 23 June 2017 at 18:03:26 UTC, Timon Gehr wrote:
On 23.06.2017 18:21, H. S. Teoh via Digitalmars-d wrote:
[...]
Agreed. Implementation:
https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax
(At most one
On Friday, 23 June 2017 at 16:21:28 UTC, H. S. Teoh wrote:
On Fri, Jun 23, 2017 at 09:06:59AM +, Solomon E via
Digitalmars-d wrote: [...]
T foo(T)(T x, T y)
in (x > 0, y > 0)
out (r; r > 0)
{
return x % y + 1;
}
Hmm, I like this syntax for out-contracts! It borrows from
On Friday, 23 June 2017 at 13:58:38 UTC, Moritz Maxeiner wrote:
OT: Anyone interested in a DIP for more template constraint
unfulfilled information in a consistent way to contracts (?) :
---
int myFunc(Args...)(Args args)
if (Args.length > 0, "Starving!")
if (Args.length > 1, "Still
On Friday, 23 June 2017 at 13:00:30 UTC, Steven Schveighoffer
wrote:
On 6/23/17 5:06 AM, Solomon E wrote:
What I expected from my impression of existing D syntax was
that something like this might be coming up:
T foo(T)(T x, T y)
in (x > 0, y > 0)
out (r; r > 0)
{
return x % y
On Friday, 23 June 2017 at 09:06:59 UTC, Solomon E wrote:
What I expected from my impression of existing D syntax was
that something like this might be coming up:
T foo(T)(T x, T y)
in (x > 0, y > 0)
out (r; r > 0)
{
return x % y + 1;
}
`out ()` has syntax similar to `foreach` and
On Friday, 23 June 2017 at 00:17:23 UTC, Steven Schveighoffer
wrote:
We can call that contextual "keyword" result. Doesn't have to
be a keyword, just the implied return value symbol name.
Another problem is that any given contextual reserved identifier
you choose will run the risk of
On Friday, 23 June 2017 at 00:17:23 UTC, Steven Schveighoffer
wrote:
int foo()
out(result)
{
}
what does this mean? Does it mean assert(result) on the out
contract, or this is the old form of out?
If we didn't have contract syntax already, and many existing
code bases that use it, I'd say
On Thursday, 22 June 2017 at 21:56:29 UTC, Timon Gehr wrote:
On 22.06.2017 23:51, MysticZach wrote:
On Thursday, 22 June 2017 at 21:41:55 UTC, MysticZach wrote:
The whole double parentheses is a bit ugly to me. Is there
any problem with
out(return > 0)
instead of
out(r) (r > 0)
I'm sorry, I
On Thursday, 22 June 2017 at 21:41:55 UTC, MysticZach wrote:
The whole double parentheses is a bit ugly to me. Is there any
problem with
out(return > 0)
instead of
out(r) (r > 0)
I'm sorry, I didn't read closely. I think that's just asking for
trouble, wanting to use `return` as an
On Thursday, 22 June 2017 at 20:02:17 UTC, jmh530 wrote:
On Thursday, 22 June 2017 at 18:57:40 UTC, MysticZach wrote:
[snip]
I don't mind that so much, but you made a good point earlier on
how out would work with it.
The whole double parentheses is a bit ugly to me. Is there any
problem
On Thursday, 22 June 2017 at 14:08:32 UTC, jmh530 wrote:
My recollection is that the most significant reason to use
contracts in D is because of contract inheritance. There's a
lot of focus in this discussion on normal functions, when I
would say that contracts really aren't even needed.
So
On Thursday, 22 June 2017 at 13:11:12 UTC, MysticZach wrote:
As long as one is doing this, maybe a proposal for user-defined
`assert` should be provided too? It'd be interesting to have a
dedicated file for user-defined assert and contract
configuration. The core idea is to allow *everyone*,
On Thursday, 22 June 2017 at 12:54:00 UTC, MysticZach wrote:
On Thursday, 22 June 2017 at 10:59:18 UTC, Moritz Maxeiner
wrote:
Again, that's not what H.S. Teoh's proposal would do. All it
does is install an *implementation agnostic*, *abtract* way to
specify contracts into the grammar. Whether
On Thursday, 22 June 2017 at 10:59:18 UTC, Moritz Maxeiner wrote:
Again, that's not what H.S. Teoh's proposal would do. All it
does is install an *implementation agnostic*, *abtract* way to
specify contracts into the grammar. Whether that is lowered to
assert, or anything else is an
On Thursday, 22 June 2017 at 12:21:29 UTC, MysticZach wrote:
I start to get the nagging feeling that your point about the
limitation in D's DbC implementation is actually the fatal flaw
here. It's currently _illegal_ (outside of interface
declarations) to expose the signature separately from
On Thursday, 22 June 2017 at 06:43:38 UTC, H. S. Teoh wrote:
On Thu, Jun 22, 2017 at 05:46:06AM +, MysticZach via
Digitalmars-d wrote: [...]
As far as syntax subtrees not belonging to their parent, I can
see where the cognitive dissonance comes from. But it just
doesn't seem that bad to me
On Wednesday, 21 June 2017 at 19:34:53 UTC, H. S. Teoh wrote:
This is a sticky point about D's current DbC implementation
that myself and several others feel is a design flaw. In
particular, that in-contracts are executed as part of the
*callee*, when the intent of DbC is really that it is the
On Thursday, 22 June 2017 at 00:27:38 UTC, Timon Gehr wrote:
On 21.06.2017 19:39, MysticZach wrote:
My counterargument to that is that it's possible that the
cognitive dissonance only occurs because of what people are
used to, rather than what is inherent to the syntax.
This is a purely
On Wednesday, 21 June 2017 at 18:04:07 UTC, Moritz Maxeiner wrote:
On Wednesday, 21 June 2017 at 17:55:05 UTC, MysticZach wrote:
Question: If `assert` itself allowed a user-defined hook, what
would the remaining justification be for decoupling `in` and
`out` contracts from the `assert` logic?
On Wednesday, 21 June 2017 at 17:38:02 UTC, Moritz Maxeiner wrote:
But another option is simply to upgrade `assert` to make sure
it offers what everyone wants.
That would be really cool, but I doubt it will be feasible
here. I think that in this case it will more likely end up with
everyone
On Wednesday, 21 June 2017 at 15:18:21 UTC, Timon Gehr wrote:
On 21.06.2017 02:51, MysticZach wrote:
I think people could get used to the cognitive dissonance.
That's really not what D is about.
My counterargument to that is that it's possible that the
cognitive dissonance only occurs
On Wednesday, 21 June 2017 at 14:49:09 UTC, Moritz Maxeiner wrote:
On Wednesday, 21 June 2017 at 13:24:24 UTC, MysticZach wrote:
So weird how this discussion is happening in parallel with
this other discussion :-) :
http://forum.dlang.org/post/rkdpuuggltowhqmcm...@forum.dlang.org
It is,
On Wednesday, 21 June 2017 at 14:22:52 UTC, Moritz Maxeiner wrote:
If you do accidentally forget the extra set of parens on the
`out` contract, you would get "Error: `do` expected before
function body after a bracketed `out` contract" at the end of
the function.
(If, however, it a happens to
On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:
there, of course, *IS* The difference. besides the aesthetical
one (seeing failed condition immediately "clicks" in your head,
and generic "assertion failed" message is only frustrating),
there may be the case when source code changed
On Wednesday, 21 June 2017 at 09:10:33 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 05:19:26 UTC, H. S. Teoh wrote:
Umm... I think we're not quite on the same page here. What
*else* are people supposed to use inside their contracts
besides the built-in assert??
I believe `assert`
On Wednesday, 21 June 2017 at 12:05:55 UTC, Moritz Maxeiner wrote:
On Wednesday, 21 June 2017 at 09:53:40 UTC, meppl wrote:
On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC,
On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner
wrote:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in (args[0] != 0)
in (args[1] > 1)
out (result => result > 0) { ... }
---
- in contracts take a
On Wednesday, 21 June 2017 at 05:19:26 UTC, H. S. Teoh wrote:
On Wed, Jun 21, 2017 at 01:06:40AM +, MysticZach via
Digitalmars-d wrote:
On Tuesday, 20 June 2017 at 21:04:16 UTC, Steven Schveighoffer
wrote:
> This is much much better. The verbosity of contracts isn't
> really the
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner wrote:
What *I* need from a DIP that addresses DbC in D (to make it
viable for me) is to make the simple case as easy as possible
to read while not introducing language inconsistencies.
With that in mind I am strongly in favor of the
On Tuesday, 20 June 2017 at 21:04:16 UTC, Steven Schveighoffer
wrote:
On 6/20/17 1:42 PM, H. S. Teoh via Digitalmars-d wrote:
Here's my counter-proposal: since the sig constraint line uses
parentheses (and yes, I deliberately planted a sig constraint
above just
to make this point), why not go
On Tuesday, 20 June 2017 at 17:42:13 UTC, H. S. Teoh wrote:
What would a body-less declaration of a function look like
under the new syntax? Hopefully not this:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in assert(args[0] != 0);// semicolon: ouch
On Wednesday, 14 June 2017 at 12:53:21 UTC, MysticZach wrote:
On Wednesday, 14 June 2017 at 12:17:50 UTC, Mike Parker wrote:
In this thread, I'm specifically looking for feedback on my
updates to the readme and the guidelines. Sorry for any
confusion.
s/GUIDLINES.md/GUIDELINES.md/
In the
On Wednesday, 14 June 2017 at 12:17:50 UTC, Mike Parker wrote:
In this thread, I'm specifically looking for feedback on my
updates to the readme and the guidelines. Sorry for any
confusion.
s/GUIDLINES.md/GUIDELINES.md/
On Wednesday, 14 June 2017 at 10:32:50 UTC, Andre Pany wrote:
[3] https://github.com/dlang/DIPs/pull/71
Hi,
the work on this dip is highly appreciated. For my AWS SDK this
DIP would
make the coding much more readable and also smaller for several
use cases.
At this point in the process,
On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:
On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:
Very nice post!
Thanks! If it gets half as many page views as yours did, I'll
be happy. Yours is the most-viewed post on the blog -- over
1000 views more than #2 (my
On Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote:
DIP 1008 is titled "Exceptions and @nogc".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md
I would like the DIP to fully articulate the choice that it's
facing, that special-casing the language for `throw new` comes
with
On Sunday, 4 June 2017 at 03:01:41 UTC, Walter Bright wrote:
On 6/3/2017 5:20 PM, Mike Parker wrote:
There's currently a proposal in the PR queue to enhance the
contract syntax.
https://github.com/dlang/DIPs/pull/66
I know. That's as it should be!
Well that's encouraging! Thanks!
On Tuesday, 30 May 2017 at 19:29:38 UTC, deadalnix wrote:
What are your thoughts? Has something similar been proposed
before?
https://wiki.dlang.org/DIP30
Also, while no syntax is provided, this is how SDC works
internally and this is how it can handle multiple context
pointers.
FWIW, I
On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and
Andrei have approved his proposal to remove body as a keyword.
I've added a summary of their decision to the end of the DIP
for anyone who cares to read it. In short:
* body
On Friday, 26 May 2017 at 01:23:59 UTC, Timon Gehr wrote:
On 25.05.2017 20:57, MysticZach wrote:
struct body {}
interface I {
int foo(int i)
in { assert(i); }
body bar();
}
The ambiguity is fixable by modifying the parser to look ahead
after `body` for `{`. Since virtual interface
On Thursday, 25 May 2017 at 11:49:47 UTC, MysticZach wrote:
...there is no known possibility of semantic confusion between
the two potential uses of `body`,
I spoke too soon. I found a place where such semantic ambiguity
is possible. It can only occur in interface declarations, and
will not
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM ET
on May 26 (3:59 AM GMT on May 27), the community has the
opportunity to provide last-minute feedback. If you
On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:
On Monday, 22 May 2017 at 15:17:24 UTC, Stanislav Blinov wrote:
On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally
On Tuesday, 23 May 2017 at 22:40:43 UTC, Martin Nowak wrote:
The proposal is a very mechanical fix, throwing several special
cases at one specific problem.
Why does it have to be refcounted? Seems like there is only
ever one reference to the current exception (the catch
variable).
The only
On Tuesday, 23 May 2017 at 19:04:46 UTC, arturg wrote:
how about @uda based contracts?
@in(x => x < 100)
@out((ret) { assert(ret > 0, "some text"); })
int fun(int i) { return someVal; }
they could also be used on type definitions,
@out((t) { assert(t); })
class NotNull {}
or temporarly on
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
I think there are several issues at hand, and they need to be
dealt with individually:
1. `body` is a very useful identifier. It would be nice to have
it available.
2. Contract syntax is too verbose.
3. a. Some people think code
I made a pull request for a new DIP dealing with contract syntax:
https://github.com/dlang/DIPs/pull/66
I write the DIP in response to the discussions for DIP 1003:
http://forum.dlang.org/thread/wcqebjzdjxldeywlx...@forum.dlang.org
This DIP is not under any kind of formal review yet. I just
On Thursday, 18 May 2017 at 01:52:17 UTC, Adam D. Ruppe wrote:
On Tuesday, 16 May 2017 at 14:17:41 UTC, Adam D. Ruppe wrote:
Similarly, what I want to see in the future is highlighting of
specific parts of code where the error applies.
Fear me. I combined Walter's code with my own to form
On Thursday, 18 May 2017 at 13:06:38 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 18 May 2017 at 12:56:31 UTC, Meta wrote:
This is pretty much the same as option 2. The short-term
contextual part is covered by Walter's suggestion.
No it's not. What MysticZach suggests, and what I
On Thursday, 18 May 2017 at 05:43:48 UTC, Manu wrote:
On 17 May 2017 at 00:51, Benro via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
[...]
4 Hours work. Discouraged and gave up after this.
Visual Studio proper is the only IDE that 'just works' well,
VisualD is
very good.
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
http://forum.dlang.org/post/kybywnscisxpebezw...@forum.dlang.org ) represents
yet another distinct option. i.e. continue to allow `body`, but make it
optional, that is, you can simply omit it if you want, while also allowing it
as an
On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
I'll add this option to the DIP.
https://github.com/dlang/DIPs/pull/65
I think (
http://forum.dlang.org/post/kybywnscisxpebezw...@forum.dlang.org
) represents yet another distinct
On Wednesday, 17 May 2017 at 09:57:41 UTC, Basile B. wrote:
On Wednesday, 17 May 2017 at 09:53:49 UTC, MysticZach wrote:
Option 4) Keep `body`, but make it both contextual *and*
optional. It becomes usable as an identifier, and those who
think it's unnecessary are appeased. The downside is
On Wednesday, 17 May 2017 at 08:03:13 UTC, Mike Parker wrote:
* Is it a good idea to remove body's status as a reserved
keyword?
* If so, which option is best?
1) Make it contextual
2) Replace it with another keyword (`function` was suggested
in the DIP, `do` in this thread).
3) A
On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
To me, it's actually worse, because now you have a visual
conflation with do-loops.
Overall, what I don't like about contract syntax is that it is
so unbearably verbose. It's not just the in and out blocks and
the (IMO redundant)
On Tuesday, 16 May 2017 at 17:42:11 UTC, MysticZach wrote:
On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}
Are you really arguing for this?
I don't want to write code like this.
It's not any better than
On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}
Are you really arguing for this?
I don't want to write code like this.
It's not any better than this:
auto foo()in{
assert(true);
}out{
assert(true);
On Tuesday, 16 May 2017 at 13:50:59 UTC, Jonathan M Davis wrote:
All I'm arguing for is that if we're removing body as a
keyword, there's no need to replace it with function or any
other word in contracts. We can simply deprecate its use as a
keyword and not replace it, letting it then be used
On Tuesday, 16 May 2017 at 03:44:54 UTC, MysticZach wrote:
It seems to me that the compiler could detect a presence or
lack of a body simply by the presence or absence of any
statement after the contracts, i.e.,
interface D {
// fun is implicitly overridable here
int fun() {
in
On Saturday, 13 May 2017 at 14:41:50 UTC, Stanislav Blinov wrote:
file(line): Error: template foo cannot deduce function from
argument types !()(int, string), candidates are:
file(line): foo(Args...)(auto ref Args arg) if
(!anySatisfy!(isString, Args))
Ya know, even a simple new line before
On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
Not that a whole new way of doing things is called for... but
I think a better design would have been to allow 'in' and
'out' statements in the function itself, with no need for
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
Not that a whole new way of doing things is called for... but I
think a better design would have been to allow 'in' and 'out'
statements in the function itself, with no need for brackets if
you only have one line's worth of contract,
On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
Why would we want to introduce function as an alternative to
body? Personally, I've always found the need to use body to be
very odd and annoying. It doesn't need to be there when you
don't have in or out contracts, and it just
On Sunday, 14 May 2017 at 16:25:36 UTC, Walter Bright wrote:
On 5/14/2017 9:04 AM, Andre Pany wrote:
Thanks a lot. In my opinion these kind of changes are small
but have huge impact
on the acceptance of a language.
I agree. A couple other improvements needed for error messages:
In the PR
On Saturday, 6 May 2017 at 22:12:10 UTC, Joshua Niehus wrote:
On Saturday, 6 May 2017 at 08:03:11 UTC, Mike Parker wrote:
https://www.youtube.com/watch?v=XTtruC3D2Ag
Is anyone else having issues viewing the livestream?
It's over. The video has already been take down. They will chop
it into
On Thursday, 4 May 2017 at 13:19:43 UTC, MysticZach wrote:
On Thursday, 4 May 2017 at 08:04:22 UTC, Timon Gehr wrote:
On 03.05.2017 01:09, MysticZach wrote:
That's true. Two points, though: If the range of error is
within
1/(n*(n-1)), with array length n,
It's not though. For example,
On Thursday, 4 May 2017 at 08:04:22 UTC, Timon Gehr wrote:
On 03.05.2017 01:09, MysticZach wrote:
Counterexample: [1,1,1,0,0]
Your algorithm returns 0 with probability 7/20, 1 with
probability
6/20 and 2 with probability 7/20.
Note that there is a simple reason why your algorithm cannot
On Tuesday, 2 May 2017 at 23:09:54 UTC, MysticZach wrote:
On Tuesday, 2 May 2017 at 21:00:36 UTC, Timon Gehr wrote:
On 02.05.2017 22:42, MysticZach wrote:
On Tuesday, 2 May 2017 at 13:44:03 UTC, MysticZach wrote:
for (;;) {
if (P(a[i]))
return i;
++count;
if
On Tuesday, 2 May 2017 at 21:00:36 UTC, Timon Gehr wrote:
On 02.05.2017 22:42, MysticZach wrote:
On Tuesday, 2 May 2017 at 13:44:03 UTC, MysticZach wrote:
for (;;) {
if (P(a[i]))
return i;
++count;
if (count == length)
return -1;
i += hop;
if
On Tuesday, 2 May 2017 at 13:44:03 UTC, MysticZach wrote:
1. Test a random element in the array. If it satisfies P,
return it.
2. Choose a hopper interval, h, that is relatively prime to the
number of elements in the array, n. You could do this by
randomly selecting from a pre-made list of
On Tuesday, 2 May 2017 at 11:27:17 UTC, Ivan Kazmenko wrote:
On Tuesday, 2 May 2017 at 10:35:46 UTC, Ivan Kazmenko wrote:
I hope some part of the idea is still salvageable.
For example, what if we put the intervals in a queue instead
of a stack?
I tried to implement a similar approach, but
On Monday, 1 May 2017 at 16:56:58 UTC, MysticZach wrote:
The goal is to have the first hit be the one you return. The
method: if a random pick doesn't satisfy, randomly choose the
partition greater than or less than based on
uniform(0..array.length-1), and do the same procedure on that
On Monday, 1 May 2017 at 16:56:58 UTC, MysticZach wrote:
// choose a random partition proportionally
auto j = uniform(da.length - 1);
if (j < i) {
// the lower partition
int a = randomlySatisfyImpl(da[0..i], j);
if (a != -1) return a;
else return
On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
Given a set A of n elements (let's say it's a random-access
range of
size n, where n is relatively large), and a predicate P(x) that
specifies some subset of A of elements that we're interested
in, what's
the best algorithm (in terms of
On Sunday, 9 April 2017 at 20:14:24 UTC, Walter Bright wrote:
... a general mechanism for safe refcounting of classes has
eluded us.
Regardless of my other comments, which are maybe a little
uninformed, DIP74 seems pretty good:
https://wiki.dlang.org/DIP74
Manu started a thread asking
On Wednesday, 12 April 2017 at 19:01:25 UTC, Walter Bright wrote:
On 4/11/2017 10:24 AM, MysticZach wrote:
Hi guys. Hey Walter. So, about this point. On the lifetime
study thread,
http://forum.dlang.org/post/56301a8c.1060...@erdani.com , the
following two
problems were stated by Andrei, but I
On Sunday, 9 April 2017 at 20:14:24 UTC, Walter Bright wrote:
On 4/9/2017 1:16 AM, Daniel N wrote:
... but why not go all the way, making it "always" refcounted?
(for any "new E",
not emplace).
Backwards compatibility, for one. For another, a general
mechanism for safe refcounting of
98 matches
Mail list logo
