Messages

61

Ideas / Re: Switch proposal

« on: November 28, 2018, 12:45:15 PM »

Also to discuss, should we automatically open a scope or not. If we automatically open a scope in cases, we prevent this nice code:

Code: [Select]

switch (state) {
  case READ_WITH_LOCK:;
    LOCK *lock = acquire_lock();
    defer lock.release();
  case READ_WITHOUT_LOCK:
    read_from_resource();
    break;
  case ...
}

This since the implicit scope would trigger the defer when passing into the READ_WITHOUT_LOCK (I assume current syntax, so this is fallthrough automatically)

Of course, we could make | / fallthrough mean that scope is shared. That would make this execute correctly (new syntax):

Code: [Select]

switch (state) {
  case READ_WITH_LOCK:;
    LOCK *lock = acquire_lock();
    defer lock.release();
  | case READ_WITHOUT_LOCK:
    read_from_resource();
  case ...
}


62

Ideas / Re: Switch proposal

« on: November 28, 2018, 12:39:22 PM »

And the uniform | syntax instead:

Real life example of this kind of switch:

Code: [Select]

switch (D->getKind()) {
    case DECL_FUNC:
        expr->setConstant();
    case DECL_VAR:
        VarDecl* VD = cast<VarDecl>(D);
        QualType T = VD->getType();
        if (T.isConstQualified()) {
            Expr* Init = VD->getInitValue();
            if (Init) {
                // Copy CTC status of Init Expr
                expr->setCTC(Init->getCTC());
            }
            expr->setConstant();
            return;
        }
    case DECL_ENUMVALUE:
        expr->setCTC(CTC_FULL);
        expr->setConstant();
        return;
    case DECL_ALIASTYPE:
    | case DECL_STRUCTTYPE:
    | case DECL_ENUMTYPE:
    | case DECL_FUNCTIONTYPE:
        expr->setConstant();
    case DECL_ARRAYVALUE:
    | case DECL_IMPORT:
    | case DECL_LABEL:
        // do nothing.
}


63

Ideas / Re: Switch proposal

« on: November 28, 2018, 12:38:02 PM »

Real life example of this kind of switch:

Code: [Select]

switch (D->getKind()) {
    case DECL_FUNC:
        expr->setConstant();
    case DECL_VAR:
        VarDecl* VD = cast<VarDecl>(D);
        QualType T = VD->getType();
        if (T.isConstQualified()) {
            Expr* Init = VD->getInitValue();
            if (Init) {
                // Copy CTC status of Init Expr
                expr->setCTC(Init->getCTC());
            }
            expr->setConstant();
            return;
        }
    case DECL_ENUMVALUE:
        expr->setCTC(CTC_FULL);
        expr->setConstant();
        return;
    case DECL_ALIASTYPE |
    case DECL_STRUCTTYPE |
    case DECL_ENUMTYPE |
    case DECL_FUNCTIONTYPE |
        expr->setConstant();
    case DECL_ARRAYVALUE |
    case DECL_IMPORT |
    case DECL_LABEL:
}


64

Ideas / Switch proposal

« on: November 28, 2018, 12:27:25 PM »

Putting it here instead as a comment in a longer discussion

Here is the propsal:

Code: [Select]

switch (a) {
  case 1 |  // Using : instead of | is syntax sugar for case 1: goto next;
  case 2 |
  case 3:
    foo();  // With : we get a break;
  case 4 |
  case 5:
    bar();
    goto next; // If we want to execute a statement then pass to next.
  case 6:
    baz();
}

// The above in C:
switch (a) {
  case 1:
  case 2:
  case 3:
    foo();
    break;
  case 4:
  case 5:
    bar();
  case 6:
    baz();
    break;
}

Another possibility is |: or :|

Code: [Select]

switch (foo) {
  case 1|:
  case 2|:
  case 3:
     do_something();

Using | means a that some care must be taken if there is an expression of type:

case 1|2: (This is is compiled to case 3: or course, but I think it's reasonable to require ( ) on any constant expression that isn't a literal.

So case 1+2: would not be allowed, but case (1+2): is ok.

Alternatives to goto next would be:

Code: [Select]

case 4:
   foo();
   fallthrough;
 case 5:
   ...

 case 4:
   foo();
   goto case 5;
 case 5:
   ...

 case 4:
   foo();
   goto case;
 case 5:
   ...

 case 4:
   foo();
   continue case;
 case 5:
   ...

 case 4:
   foo();
   next;
 case 5:
   ...

 case 4:
   foo();
   next case;
 case 5:
   ...

 case 4:
   foo();
   nextcase;
 case 5:
   ...

An even more lightweight syntax uses | for fallthrough, leading to this uniform syntax look:

Code: [Select]

  case 4:
   foo();
  | case 5:
   ...


Code: [Select]

switch (a) {
  case 1:
  | case 2:
  | case 3:
    foo();  // implicit break here
  case 4 :
  | case 5:
    bar();  // Fallthrough here because the next starts with |
  | case 6:
    baz();
}


65

Implementation Details / Re: LLVM/C gen

« on: November 27, 2018, 05:24:43 PM »

Should we try to integrate the diagnostics or not?

66

Implementation Details / Re: Code formatting of C2's c++

« on: November 27, 2018, 04:03:50 PM »

I think any else without { } is bad, so:

Code: [Select]

if (x) func1();
else func2();

Would also be a no-go from my perspective, to the point that I would consider changing grammar so that if-else WOULD NEED to be written with blocks.

So:

Good

Code: [Select]

if (foo) bar();

if (foo) {
  bar();
} else {
  baz();
}

if (foo) {
  bar();
} else if (foo2) {
  baz();
}

Accepted by C2, but not in C2 C++ formatting

Code: [Select]

if (foo)
  bar();

Not accepted by C2, not allowed in C2's C++ formatting

Code: [Select]

if (foo) bar();
else baz();

if (foo) {
  bar();
} else baz();

if (foo) bar();
else {
  baz();
}


67

Implementation Details / Suppress warnings

« on: November 27, 2018, 02:57:12 PM »

Suppressing warnings should be easy to do on a file / func / statement.

In IntelliJ, annotations are used to suppress warnings on file / class / method level, but can be suppressed by statement with a comment as well, in this manner:

Code: [Select]

// noinspection unchecked
Map<String, List<String>> nameMap = (Map)result.get("names");

For Xcode / Clang, it's much more complicated. You push the current state with a pragma, disable a warning and then have to pop it later. Very ugly:

Code: [Select]

#pragma clang diagnostic push
#pragma ide diagnostic ignored "UnusedValue"
lSeek += file_info.size_file_comment - uSizeRead;
#pragma clang diagnostic pop

I'd like for C2 to have a very easy way to suppress warnings in the manner of IntelliJ's comments.

Something like this:

Code: [Select]

// A.
lSeek += file_info.size_file_comment - uSizeRead; // $ignoreunused$

// B.
lSeek /* $ignoreunused$ */ += file_info.size_file_comment - uSizeRead;

// C.
// $ignoreunused$
lSeek += file_info.size_file_comment - uSizeRead;

// D.
// {unchecked:warn_unused}
lSeek += file_info.size_file_comment - uSizeRead;

Other styles are possible as well. The same should go for other scopes:

Code: [Select]

// {unchecked:warn_unused}
func i32 foo() {
   ...
}

// {unchecked:warn_unused}
type Foo struct {
   ...
}

For file scope it should be slightly different to avoid parsing ambiguity.

68

General Discussion / Re: Overwriting fields in init struct.

« on: November 27, 2018, 02:42:24 PM »

Should the error on overwriting fields in init struct stay? Or just a warning that can be overridden?

69

General Discussion / Re: Are modules always single level or is there any (future) concept of nesting

« on: November 27, 2018, 02:40:57 PM »

That's fine with me. Might be useful to have that documented though. I only knew from certain from reading the source

70

General Discussion / Discussions where?

« on: November 25, 2018, 11:50:11 PM »

Github issues, this forum or emails? What's the best place for feature suggestions and other ideas for improvement? I note that I'm writing all over the place and maybe it would be best to stick with Github issues?

71

General Discussion / Are modules always single level or is there any (future) concept of nesting

« on: November 20, 2018, 08:05:55 PM »

C++ allows nested namespaces, which means we can have foo::bar::baz() (in C++). For C2, will modules always be single level?

For example if one encounters foo.bar.baz(), can I then be sure that foo is either the module name or the name of a variable defined in the local module – or imported as local?

And can I be sure that bar here can never be part of a module name?

I'm pretty sure that this is true right now, but what about the future – are any future ideas that could change this?

72

Ideas / Re: Macros again

« on: November 19, 2018, 03:43:54 PM »

A tiny way to modify macros would be to simply extend "#define" with a { ... } syntax:

Code: [Select]

#define ADD_TO(x, y) {
   x += y;
}

ADD_TO(x, 1)

The { } introduces a multiline macro that does not need explicit linebreaks.

Secondly we could add the "$" symbol to introduce hygienic temporaries:

Code: [Select]

#define SWAP(x, y) {
   typeof(x) $tmp = x;
   x = y;
   y = $tmp;
}

Here $tmp will actually be replaced by __<macro>_<variable_name>_<instance> when translating to C, so __SWAP_tmp_1, __SWAP_tmp_2 etc.

We then introduce the syntax macros using:

Code: [Select]

macro swap(&a, &b) {
   typeof(a) $tmp = a;
   b = a;
   a = $tmp;
}

The use of &a follows C++ standard: it simply refers to a variable OR EXPRESSION that is imported into its scope. Using the unadorned variable name as evaluated expression allows us to write this code:

Code: [Select]

macro max(a, b) {
  return (a > b ? a : b)
}

The above code is equivalent to:

Code: [Select]

macro max(&a, &b) {
  typeof(a) $tmp_a = a;
  typeof(b) $tmp_b = b;
  $tmp_a > $tmp_b ? $tmp_a : $tmp_b
}

Or in (GNU) C:

[/code]

Code: [Select]

#define max(a,b) \
   ({ __typeof__ (a) _a = (a); \
       __typeof__ (b) _b = (b); \
     _a > _b ? _a : _b; })

To recap:

1. We add the { } format to #define for multiline defines.
2. We add the $<name> format as hygienic variable names.
3. We add the syntax "macro" type of definition.
4. The syntax macro makes a difference between "normal" parameters (with & as prefix) and "evaluated" parameters (unadorned variables)

In addition we need to make macros have a definite scope. I suggest the following:

#define is always defined local to a scope (unlike in C).

This means that

Code: [Select]

#define FOO printf("foo");
{
   #define BAR printf("bar");
}
FOO // adds printf("foo");
BAR; // Error, define not available in scope;

This also means that a define can be declared public to be accessed as if defined from the top of the file scope:

Code: [Select]

// file 1
module foo
public #define FOO { printf("FOO!\n"); }

// file 2
import foo

func void test() {
  foo.FOO
}

Only defines in the file scope that exists in the file scope may be public and used in other modules.

73

Ideas / Re: Macros again

« on: November 19, 2018, 12:48:08 PM »

More about macros: http://www.wilfred.me.uk/blog/2014/09/15/comparative-macrology/

74

Ideas / Re: Keyword "void" is terrible (!!)

« on: November 18, 2018, 04:18:05 PM »

P.S. I found styling

What you found was a way to make only half of your text to fit horizontally on the screen at a time when viewed on mobile. Seriously, stop it.

75

Ideas / Re: Support of Unicode ?

« on: November 18, 2018, 04:14:46 PM »

Swift recently switched to an internal representation of UTF-8 and said it worked out to being faster than alternatives even for languages where UTF-16/32 is considered "better".

https://forums.swift.org/t/string-s-abi-and-utf-8/17676