Hi All,
Request your help on the below code as it is not working as
expected.
GetConnections.d
module common.GetConnections;
import mysql;
class Connections
{
private Connection conn;
auto constr =
"host=localhost;port=3910;user=user;pwd=password#;db=testdb";
this.conn = new
On Thursday, 22 October 2020 at 04:20:35 UTC, Mathias LANG wrote:
Unfortunately this switch still has some bugs, so you can
easily run into linker errors. I'm hoping to ultimately make it
the default though.
Which is more of a template emission problem because
`-checkaction=context` uses a
On Friday, 23 October 2020 at 04:24:09 UTC, Paul Backus wrote:
On Friday, 23 October 2020 at 00:53:19 UTC, Bruce Carneal wrote:
When you write functions, the compiler helps you out with
fully automated constraint checking. When you write templates
you can write them so that they look like
On Friday, 23 October 2020 at 00:53:19 UTC, Bruce Carneal wrote:
When you write functions, the compiler helps you out with fully
automated constraint checking. When you write templates you
can write them so that they look like simple functions, in
which case you're on pretty solid ground.
On Thursday, 22 October 2020 at 11:04:53 UTC, Vino wrote:
class Connections
{
private Connection conn;
auto constr =
"host=localhost;port=3910;user=user;pwd=password#;db=testdb";
this.conn = new Connection(constr);
}
where Connections class constructor implemented?
On Thursday, 22 October 2020 at 16:03:45 UTC, H. S. Teoh wrote:
On Thu, Oct 22, 2020 at 03:32:57PM +, Andrey Zherikov via
Digitalmars-d-learn wrote:
There are two ways how __FILE__, __LINE__ etc. can se used in
function parameters: as regular parameters and as template
parameters:
[...]
On 10/22/20 7:04 AM, Vino wrote:
Hi All,
Request your help on the below code as it is not working as expected.
GetConnections.d
module common.GetConnections;
import mysql;
class Connections
{
private Connection conn;
auto constr =
On Thursday, 22 October 2020 at 14:08:30 UTC, Steven
Schveighoffer wrote:
On 10/22/20 7:04 AM, Vino wrote:
Hi All,
Request your help on the below code as it is not working as
expected.
GetConnections.d
module common.GetConnections;
import mysql;
class Connections
{
private
There are two ways how __FILE__, __LINE__ etc. can se used in
function parameters: as regular parameters and as template
parameters:
void rt(string file=__FILE__, int line=__LINE__, string
func=__FUNCTION__)
{
writeln(file,"(",line,"): ",func);
}
void ct(string file=__FILE__, int
On Thu, Oct 22, 2020 at 03:32:57PM +, Andrey Zherikov via
Digitalmars-d-learn wrote:
> There are two ways how __FILE__, __LINE__ etc. can se used in function
> parameters: as regular parameters and as template parameters:
[...]
> What is recommended way?
> What are pros/cons of each case?
I
Is type checking in D undecidable? Per the wiki on dependent
types it sure looks like it is.
I assume that it's well known to the compiler contributors that D
type checking is undecidable which, among other reasons, is why
we have things like template recursion limits.
Confirmation of the
On Thursday, 22 October 2020 at 18:24:47 UTC, Bruce Carneal wrote:
Per the wiki on termination analysis some languages with
dependent types (Agda, Coq) have built-in termination checkers.
I assume that DMD employs something short of such a checker,
some combination of cycle detection backed up
On Thursday, 22 October 2020 at 18:33:52 UTC, Ola Fosheim Grøstad
wrote:
In general, it is hard to tell if a computation is long-running
or unsolvable.
You could even say ... it's undecidable :)
On Thursday, 22 October 2020 at 17:25:44 UTC, Bruce Carneal wrote:
Is type checking in D undecidable? Per the wiki on dependent
types it sure looks like it is.
Even if it is, you can still write something that is decidable in
D, but impractical in terms of compile time.
You probably mean
On Thursday, 22 October 2020 at 18:04:32 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 22 October 2020 at 17:25:44 UTC, Bruce Carneal
wrote:
Is type checking in D undecidable? Per the wiki on dependent
types it sure looks like it is.
Even if it is, you can still write something that is
On Thursday, 22 October 2020 at 18:38:12 UTC, Stefan Koch wrote:
On Thursday, 22 October 2020 at 18:33:52 UTC, Ola Fosheim
Grøstad wrote:
In general, it is hard to tell if a computation is
long-running or unsolvable.
You could even say ... it's undecidable :)
:-) Yes, although you can
On Thursday, 22 October 2020 at 17:25:44 UTC, Bruce Carneal wrote:
Is type checking in D undecidable? Per the wiki on dependent
types it sure looks like it is.
It is indeed undecidable. Imagine you had a decider for it.
Because CTFE is clearly turing-complete, you can express that in
a D
On 10/22/20 11:00 AM, Vino wrote:
On Thursday, 22 October 2020 at 14:08:30 UTC, Steven Schveighoffer wrote:
On 10/22/20 7:04 AM, Vino wrote:
Hi All,
Request your help on the below code as it is not working as expected.
GetConnections.d
module common.GetConnections;
import mysql;
class
On Thursday, 22 October 2020 at 18:46:07 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 22 October 2020 at 18:38:12 UTC, Stefan Koch wrote:
On Thursday, 22 October 2020 at 18:33:52 UTC, Ola Fosheim
Grøstad wrote:
In general, it is hard to tell if a computation is
long-running or unsolvable.
On Thursday, 22 October 2020 at 19:24:53 UTC, Bruce Carneal wrote:
On a related topic, I believe that type functions enable a
large amount of code in the "may be hard to prove decidable"
category (templates) to be (re)written as clearly decidable
code. Easier for the compiler to deal with
Thanks for all your answers!
On Thursday, 22 October 2020 at 19:24:53 UTC, Bruce Carneal wrote:
I dont think it is any easier to prove the "will increase
faster" proposition than it is to prove the whole thing.
They probably just impose restrictions so that they prove that
there is reduction and progress over time. One
There is a funny feature (or bug) in the D language:
static alias this and static operator overloading.
For example
interface Foo {
static {
int value;
void opAssign(int v) { value = v; }
int get() { return value; }
alias get this;
}
}
Now we can use
On Thursday, 22 October 2020 at 20:37:22 UTC, Paul Backus wrote:
On Thursday, 22 October 2020 at 19:24:53 UTC, Bruce Carneal
wrote:
On a related topic, I believe that type functions enable a
large amount of code in the "may be hard to prove decidable"
category (templates) to be (re)written as
24 matches
Mail list logo
