Welcome to the Lounge

3-Dec-19 3:29

So parsing a C# subset has lead me to all kinds of interesting questions

[System.AttributeUsage(System.AttributeTargets.All,true)]
class TestAttribute<T> : System.Attribute
{

}

does that work? (it doesn't)

why do I even ask?

because if it worked I'd have to look for

[Test<string>()] class Foo {}

and the like.

Don't get me started on the weirdities of array declarations.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

Forogar 3-Dec-19 3:56

Forogar

3-Dec-19 3:56

C#
Weirdness = job security!

- I would love to change the world, but they won’t give me the source code.

RugbyLeague3-Dec-19 4:19

3-Dec-19 4:19

This can be valid c#

public class var 
{
    async async async(async async) => await async;
}

honey the codewitch3-Dec-19 4:20

3-Dec-19 4:20

yick. Fortunately, I don't have to support any of those keywords, but i need to check to see if my stuff will parse that.

Edit: The compiler chokes on the async specifiers

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

RugbyLeague3-Dec-19 21:53

3-Dec-19 21:53

because async / await etc are new(ish) keywords there might be code out there which has types named "async", "await" so the C# compiler does context tests for new keywords - in the example I gave some are keywords, some are types (which I omitted)

honey the codewitch3-Dec-19 21:55

3-Dec-19 21:55

Yeah but in this case, the compiler I'm using (c#7? VS2017) bombs on that statement you gave me.

I know about contextual keywords as I've parsed C# quite a bit, and LINQ and other language additions have forced it. I've watched the keyword list in C# grow over time, and some old keywords like __stackalloc finally given life in the latest incarnations of the language

But async will break in the context you used it. I'm not sure about C# compilers before it was a keyword

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

RugbyLeague3-Dec-19 23:04

3-Dec-19 23:04

You need to create types with those keywords and not use var anywhere

kalberts3-Dec-19 22:39

kalberts

3-Dec-19 22:39

Like in Fortran IV where you can have an integer named REAL and a REAL named COMPLEX. No reserved words.
Or you could name your function SOLVE REAL PROBLEM. Spaces are ignored.

I don't know if these are still valid in modern variants of Fortran; I haven't written a single line of Fortran for 30 years.
(C.A.R Hoare, in the Fortran-77 discussions, stated "I don't know what programming languages will look like in year 2000, but they will be named 'Fortran'" - when I saw a few Fortran 2003, my immediate reaction was: He hit the nail on the head!)

RugbyLeague3-Dec-19 23:05

3-Dec-19 23:05

PL/1 didn't (and probably still doesn't) have any reserved words either

Richard Deeming3-Dec-19 4:25

Richard Deeming

3-Dec-19 4:25

Looks like it could be supported in C# vNext though:
Champion "Allow Generic Attributes" · Issue #124 · dotnet/csharplang · GitHub[^]

But that almost certainly means it will be tied to the .NET Core / .NET 5 runtime.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

honey the codewitch3-Dec-19 4:26

WSO CCC OTD 2019-12-03 Solution

3-Dec-19 4:26

Won't matter to me as it will never be supported by the CodeDOM =)

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

OriginalGriff3-Dec-19 1:51

3-Dec-19 1:51

They don't buzz, but they are definitely insects! (7)

HUMBUGS[^]

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!

musefan3-Dec-19 2:35

musefan

3-Dec-19 2:35

Urgh.... so obvious once you know the answer.

I gathered it would be some sort of confectionery, but the sweet shop was just too large!

OriginalGriff3-Dec-19 2:52

3-Dec-19 2:52

I'm really glad it was "obvious with the answer" - means it wasn't impossible!

So ... I'm up tomorrow ... :EvilLaugh:

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!

super3-Dec-19 3:11

super

3-Dec-19 3:11

Simple and Difficult at the same time.
Knew it was something sweet but was focusing on Honey for some reason

cheers,

Super

------------------------------------------
Too much of good is bad,mix some evil in it

OriginalGriff3-Dec-19 3:19

3-Dec-19 3:19

super wrote:
was focusing on Honey for some reason

He's busy playing with nested classes. Big Grin | :-D

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!

Just because nobody does something doesn't mean nobody should document that something

musefan3-Dec-19 4:05

musefan

3-Dec-19 4:05

That's the problem with honey, once you are in it's difficult to get out.

honey the codewitch3-Dec-19 1:30

Re: Just because nobody does something doesn't mean nobody should document that something

3-Dec-19 1:30

In C#, this is valid:

class A<T> {
   class B<TT> {
   }
}

therefore, this is valid:

typeof(A<int>.B<int>)

The trouble is, there's absolutely nothing out there online I can find about representing such a nested generic typereference as a CodeTypeReference properly.

Which leads me to an arcane comment in Microsoft's reference sourcecode - the last hope of the desperate.

// Try find the matching '[', if we can't find it, we will not try to parse the string
while (current >= 0)
{
	if (typeName[current] == '[')
	{
		// break if we found matched brackets
		if (--unmatchedRightBrackets == 0) break;
	}
	else if (typeName[current] == ']')
	{
		++unmatchedRightBrackets;
	}
	else if (typeName[current] == ',' && unmatchedRightBrackets == 1)
	{
		//
		// Type name can contain nested generic types. Following is an example:
		// System.Collections.Generic.Dictionary`2[[System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089], 
		//          [System.Collections.Generic.List`1[[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], 
		//           mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
		// 
		// Spliltting by ',' won't work. We need to do first-level split by ','. 
		//
		if (current + 1 < subTypeNameEndIndex)
		{
			subTypeNames.Push(typeName.Substring(current + 1, subTypeNameEndIndex - current - 1));
		}

		subTypeNameEndIndex = current;

	}
	--current;
}

So now I get to figure out what this is doing, just so I can figure out how to properly use what it is implementing.

Microsoft Docs: Technically correct, but practically useless. Mad | :mad:

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

OriginalGriff3-Dec-19 1:50

Re: Just because nobody does something doesn't mean nobody should document that something

3-Dec-19 1:50

I don't think that's quite the same thing is it?
The MS one is a Dictionary<string, List<int>> which isn't really "nested" in the same way as yours is.

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!

honey the codewitch3-Dec-19 1:52

Re: Just because nobody does something doesn't mean nobody should document that something

3-Dec-19 1:52

Yeah you know, i figured that out about a minute ago. *headdesk*

Sigh | :sigh:

which led me to this

var c = new CodeTypeReference();
c.BaseType = "A`1+B`1";
c.TypeArguments.Add(new CodeTypeReference("System.String"));
c.TypeArguments.Add(new CodeTypeReference("System.Int64"));
Console.WriteLine(CD.ToString(c));

which led me to figuring out kind of how it works, but it isn't pretty.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

OriginalGriff3-Dec-19 2:20

Re: Just because nobody does something doesn't mean nobody should document that something

3-Dec-19 2:20

honey the codewitch wrote:
you know, i figured that out about a minute ago

"Great minds" and all that.

Or "fools seldom differ" - your choice! Wink | ;)

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!

honey the codewitch3-Dec-19 2:21

Re: Just because nobody does something doesn't mean nobody should document that something

3-Dec-19 2:21

I think that's a perspective thing. I feel like the C# language spec is laughing at me right now.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

CPallini3-Dec-19 1:56

CPallini

3-Dec-19 1:56

Quote:
Microsoft Docs: Technically correct, but practically useless.

Still far better than most of the 'competitors' ones.

Re: Just because nobody does something doesn't mean nobody should document that something

honey the codewitch3-Dec-19 1:57