Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bas

Pages: 1 [2] 3 4 ... 15
16
Ideas / Re: Error handling [proposal]
« on: December 07, 2018, 10:40:23 AM »
The main issue I have with this approach is:
- what is the actual problem it's trying to solve?
- it makes the syntax a Lot more complex (and unreadable).
- it only helps if the error system is used universally used (like in Go). In C that will never be the case

I think the power of C(2) is it's simplicity. Code can be very readable, because once you understand
a few simple patterns, it's all the same. Like:

Code: [Select]
int fd = open(..);
if (fd == -1) {
   // error
}

So in C the pattern is to (for example) use signed values to be able to use special values (eg -1) to indicate
an error.

A more extended pattern is to always return a Result Enum, where Result_Ok is the happy flow. Other output
variables then need to be passed back via out params.

Just sticking to these patterns is so very powerfull, since all C programmers understand them from day 1.

17
General Discussion / Re: Overwriting fields in init struct.
« on: December 07, 2018, 10:26:35 AM »
I think this is again a situation that does make the language a bit more complex, while not adding much.
Let's really keep the language as simple as possible. That way, (extra) tooling could add warnings for
unset functions more easily..

18
Implementation Details / Re: LLVM/C gen
« on: December 02, 2018, 12:22:59 PM »
Can we just start without and add it when we need it?

19
Ideas / Re: Switch proposal
« on: December 02, 2018, 12:20:26 PM »
Ahh missed that sorry

I think the common case for a switch is that every case breaks. Fallthrough is a much rarer case. So I think making
all cases break by default is an improvement indeed. Syntax wise, this means the following:
- keyword break is allowed in a case.
- keyword fallthrough is used to indicate that the case will fallthrough (there must be a next case).

I'll put in on the roadmap

20
Ideas / Re: Support of Unicode ?
« on: December 02, 2018, 12:15:51 PM »
I'm not agaist Unicode in C2, but i just want in there as an optional part that you can use or not. So a basic string will Not be Unicode.

21
Ideas / Re: Typeinfo at runtime
« on: December 02, 2018, 12:11:32 PM »
For the macro system we will need something like typeof(), eg for swap() (pseudo code)

Code: [Select]
macro swap(x, y) {
   typeof(x) tmp = x;
   x = y;
   y = tmp;
}

I don't really like the vtype as it makes the language more complex again..

22
Implementation Details / Re: CTC (partial, full, none)
« on: December 02, 2018, 11:56:34 AM »
CTC = Compile Time Constant.
Code: [Select]
const i32 a = 32; // CTC full
const i32 b = a; // CTC full

// expr's:
i32 c = 10; // NOTE: c not const
3 + a; // CTC full
c; // CTC none
3 + c; // CTC partial (some sub-expr is FULL)

CTC full expressions are checked for value by the analyser (no casts needed then)

Also CTC full expressions can be evaluated at compile time and just added to the code as that value.

23
Ideas / Re: Switch proposal
« on: November 30, 2018, 05:03:55 PM »
Fallthrough is always automatic, except when you use break. So there is never an automatic break.
The compiler gives gives a warning/error if you don't use break/fallthrough in cases there is a code..

24
Ideas / Re: Support of Unicode ?
« on: November 30, 2018, 01:42:52 PM »
In all my years of programming, I've only had to do I18n twice. Both were C++ projects. In C never. In C a basic string is just a char* with 8-bit characters. That
works for 99.9% of the cases. What would be nice if we could add special Strings as an optional feature. If not used, no overhead etc.

25
General Discussion / Re: Overwriting fields in init struct.
« on: November 30, 2018, 01:19:43 PM »
Why would this not be an error?

26
General Discussion / Re: C2x
« on: November 30, 2018, 11:58:49 AM »
I always find it funny that most language seem to do well without all these big formal specification documents.

If you have concrete proposals, just make them, but there is enough work already to make this a priority..

27
Implementation Details / Re: LLVM/C gen
« on: November 30, 2018, 11:56:07 AM »
It seems like a good idea, but I haven't really focused on that part yet. What do you think?

28
Implementation Details / Re: Code formatting of C2's c++
« on: November 30, 2018, 11:49:42 AM »
You can't protect against stupidity  ;).
If people want to write that code, let them, but don't burden good/normal developers by those restrictions..

29
Implementation Details / Re: Suppress warnings
« on: November 30, 2018, 11:48:15 AM »
Yes, but i would want to avoid all the nitty-gritty Warning level tweaking that's part of C/C++. Only unused decls maybe and maybe maybe
some implicit conversions. Otherwise just be strict and generate errors. If you inherit a piece of code, disabling some warnings is okey.

What I'm thinking of is whether these adjustments should be make in code or in the recipe file. I think the recipe file might be better
suited for file-based adjustments.

30
General Discussion / Re: Overwriting fields in init struct.
« on: November 29, 2018, 08:26:05 AM »
Which unit test?

Pages: 1 [2] 3 4 ... 15